Bug#1057843: Guidelines for affected users
Meanwhile, can the ftp admins pull this faulty version? I just managed to download and install this, but fortunately didn't reboot on all of my systems before coming across this bug via LWN via reddit. If you're in such a pickle as myself, you're able to get around it for now by: apt install linux-image-amd64/bookworm-security dpkg --get-selections | grep 6.1.0.14 apt purge linux-image-6.1.0-14-amd64 (probably want to mark that one as uninstallable too, but there's only one of me, surely I'll remember not to install it at a later date??!) and at worst you'll be left on the kernel you're currently running. I am basing this off https://lwn.net/Articles/954285/ "- Stable kernels < 6.5 are affected if they have 91562895f803 (ext4 commit) - Kernels >= 6.5 are not affected, as they will _also_ have 936e114a245b6 (iomap commit)" 91562895f803 is not in 6.1.55-1 that anyone who last updated 3 weeks ago would have encountered, nor in the current bookworm-security version. -- Tim Connors
Bug#990069: Still broken in ssh 8.4p1-5, libc6 2.31-13
reopen 990069 thanks. With these packages installed: 24573,4> dpkg --get-selections | grep ssh clusterssh install libssh-4:amd64 install libssh-gcrypt-4:amd64 install libssh2-1:amd64 install openssh-client install openssh-server install openssh-sftp-server install ssh-askpass install sshfs install This particular system is sysv, but I think my other machines suffering this same problem were already on systemd by the time I upgraded. 24583,14> sudo grep -e ssh -e libc6 -e Restarting -e '^ [a-z]' -e Services /var/log/apt/term.log Replacing files in old package libc6:amd64 (2.28-10) ... Replacing files in old package libc6:i386 (2.28-10) ... Preparing to unpack .../06-openssh-sftp-server_1%3a8.4p1-5_amd64.deb ... Unpacking openssh-sftp-server (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ... Preparing to unpack .../13-openssh-client_1%3a8.4p1-5_amd64.deb ... Unpacking openssh-client (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ... Preparing to unpack .../15-openssh-server_1%3a8.4p1-5_amd64.deb ... Unpacking openssh-server (1:8.4p1-5) over (1:7.9p1-10+deb10u2) ... Preparing to unpack .../0-libc6-dev_2.31-13_amd64.deb ... Unpacking libc6-dev:amd64 (2.31-13) over (2.28-10) ... Preparing to unpack .../libc6_2.31-13_i386.deb ... De-configuring libc6:amd64 (2.28-10) ... Unpacking libc6:i386 (2.31-13) over (2.28-10) ... Preparing to unpack .../libc6_2.31-13_amd64.deb ... Unpacking libc6:amd64 (2.31-13) over (2.28-10) ... Setting up libc6:amd64 (2.31-13) ... Restarting services possibly affected by the upgrade: smbd: restarting...done. openbsd-inetd: restarting...done. exim4: restarting...done. cron: restarting...done. autofs: restarting...done. atd: restarting...done. Services restarted successfully. Setting up libc6:i386 (2.31-13) ... Preparing to unpack .../libc6-dbg_2.31-13_amd64.deb ... Unpacking libc6-dbg:amd64 (2.31-13) over (2.28-10) ... Restarting services possibly affected by the upgrade: samba-ad-dc: stopping...starting...done. smbd: stopping...starting...done. exim4: stopping...starting...done. cron: stopping...starting...done. atd: stopping...starting...done. Services restarted successfully. Preparing to unpack .../137-libssh-gcrypt-4_0.9.5-1+deb11u1_amd64.deb ... Unpacking libssh-gcrypt-4:amd64 (0.9.5-1+deb11u1) over (0.8.7-1+deb10u1) ... At this point, there's: 24572,2> ls -lA /etc/init.d/ssh* -rwxr-xr-x 1 root root 3939 Feb 1 2020 /etc/init.d/ssh -rwxr-xr-x 1 root root 4056 Mar 13 2021 /etc/init.d/ssh.dpkg-new and ssh isn't yet started - I did that manually because I knew the problem was going to arise. -- Tim Connors
Bug#844285: pidgin: steals (warps) mouse cursor (not just focus) when new message comes in [SEC=UNCLASSIFIED]
Package: pidgin Version: 2.11.0-0+deb8u1 Severity: grave Tags: security Justification: user security hole Dear Maintainer, Like bugs #399786 and #518339, the mouse is warped to an open conversation window when a new message comes into that conversation. Typing a password at the time, and your password gets entered into that conversation. Never steal focus - there is never any valid reason for it. Especially not something as unimportant as a chat program. There appears to be no setting in preferences or plugins to disable this brain damage. -- System Information: Debian Release: 8.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.8.4-040804-generic (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pidgin depends on: ii gconf2 3.2.6-3 ii libatk1.0-0 2.14.0-1 ii libc6 2.23-5 ii libcairo2 1.14.0-2.1+deb8u1 ii libdbus-1-3 1.10.10-1 ii libdbus-glib-1-20.102-1 ii libfontconfig1 2.11.0-6.3+deb8u1 ii libfreetype62.5.2-3+deb8u1 ii libgadu31:1.12.0-5 ii libgdk-pixbuf2.0-0 2.31.1-2+deb8u5 ii libglib2.0-02.48.0-1~bpo8+1 ii libgstreamer0.10-0 0.10.36-1.5 ii libgtk2.0-0 2.24.25-3+deb8u1 ii libgtkspell02.0.16-1.1 ii libice6 2:1.0.9-1+b1 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libpangoft2-1.0-0 1.36.8-3 ii libpurple0 2.11.0-0+deb8u1 ii libsm6 2:1.2.2-1+b1 ii libx11-62:1.6.2-3 ii libxml2 2.9.1+dfsg1-5+deb8u3 ii libxss1 1:1.2.2-1 ii perl-base [perlapi-5.20.2] 5.20.2-3+deb8u6 ii pidgin-data 2.11.0-0+deb8u1 Versions of packages pidgin recommends: ii gstreamer0.10-alsa 0.10.36-2 pn gstreamer0.10-ffmpeg ii gstreamer0.10-plugins-base 0.10.36-2 ii gstreamer0.10-plugins-good 0.10.31-3+nmu4+b1 Versions of packages pidgin suggests: ii libsqlite3-0 3.8.7.1-1+deb8u2 -- no debconf information
Bug#734688: Logs are not rotated for a month
On Wed, 16 Dec 2015, Michael Gebetsroither wrote: > Package: logrotate > Version: 3.8.7-1+b1 > Followup-For: Bug #734688 > > Dear Maintainer, > > Seconded, the problem still persists in jessie. > Logrotate was practically broken after /var/log got full a month ago. > > There where various .log.1.gz files, most of which where 0 bytes which > stopped logrotate to act on those files completely. > > # grep 'error creating output file' logrotate_force_20151216.log > error: error creating output file /var/log/dpkg.log.1.gz: File exists > error: error creating output file /var/log/alternatives.log.1.gz: File exists > error: error creating output file /var/log/nginx/error.log.1.gz: File exists > error: error creating output file /var/log/nginx/access.log.1.gz: File exists > error: error creating output file /var/log/php5-fpm.log.1.gz: File exists > error: error creating output file /var/log/syslog.1.gz: File exists > error: error creating output file /var/log/daemon.log.1.gz: File exists > error: error creating output file /var/log/auth.log.1.gz: File exists > error: error creating output file /var/log/messages.1.gz: File exists And in my case, it wasn't a 0 byte file - there was syslog.1 and syslog.1.gz, both largish. It is possible gzip simply failed the first time because I ran out of space. 2 observations: 1) logrotate didn't output any diagnostics, or exit non zero. Consequently, I noticed nothing in my cron.daily email for a month. I only noticed when a usb failure meant the syslog file grew enormously, and I saw the top of the messages were from a month prior. 2) All these suggestions of heuristics about deleting a file if 0 sized and created immediately before etc. Why not just, when logrotate finds a base file whose .gz already exists, recursively call itself again to start rotating down to the current file, which can then be compressed and resume where we were? Sorry no patches, already after my bedtime, and this has already been languishing in my todo list for a couple of weeks. -- Tim Connors
Bug#753133: postr: flickr API went SSL only today
Package: postr
Version: 0.13-1
Severity: grave
Tags: patch
Justification: renders package unusable
API went SSL only today:
https://www.flickr.com/help/forum/en-us/72157645440333073/
My basic little patch seems to work for the handful of things I've
tried, but I've probably missed something.
Also need to add a dependency on python-openssl. My patch doesn't do
that since I'm a bit clueless.
-- System Information:
Debian Release: 7.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (2,
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.13-0.bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages postr depends on:
ii chromium [www-browser]35.0.1916.153-1~deb7u1
ii google-chrome-unstable [www-browser] 37.0.2054.3-1
ii iceweasel [www-browser] 24.6.0esr-1~deb7u1
ii konqueror [www-browser] 4:4.8.4-2
ii links [www-browser] 2.7-1+deb7u1
ii lynx-cur [www-browser]2.8.8dev.12-2
ii python2.7.6-2
ii python-bsddb3 6.0.1-1+b1
ii python-gconf 2.28.1+dfsg-1
ii python-glade2 2.24.0-3+b1
ii python-gnome2 2.28.1+dfsg-1
ii python-gtk2 2.24.0-3+b1
ii python-nautilus 1.1-3
ii python-twisted-web12.0.0-1
ii w3m [www-browser] 0.5.3-8
postr recommends no packages.
postr suggests no packages.
-- no debconf information
Description: Attempt to move to https API: https://www.flickr.com/help/forum/en-us/72157645440333073/
---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:
Origin: ,
Bug:
Bug-Debian: http://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded:
Reviewed-By:
Last-Update:
--- postr-0.13.orig/src/flickrest.py 2014-06-29 20:52:37.0 +1000
+++ postr-0.13/src/flickrest.py 2014-06-29 23:26:15.227424687 +1000
@@ -47,7 +47,7 @@
SIZE_LARGE) = range (0, 5)
class Flickr:
-endpoint = "http://api.flickr.com/services/rest/?";
+endpoint = "https://api.flickr.com/services/rest/?";
def __init__(self, api_key, secret, perms="read"):
self.__methods = {}
@@ -208,7 +208,7 @@
}
self.logger.info("Calling upload")
-return client.upload("http://api.flickr.com/services/upload/";,
+return client.upload("https://api.flickr.com/services/upload/";,
proxy=self.proxy, method="POST",
headers=headers, postdata=form,
progress_tracker=progress_tracker).addCallback(self.__cb, "upload")
@@ -245,7 +245,7 @@
keys = { 'perms': self.perms,
'frob': frob }
self.__sign(keys)
-url = "http://flickr.com/services/auth/?api_key=%(api_key)s&perms=%(perms)s&frob=%(frob)s&api_sig=%(api_sig)s" % keys
+url = "https://flickr.com/services/auth/?api_key=%(api_key)s&perms=%(perms)s&frob=%(frob)s&api_sig=%(api_sig)s" % keys
return {'url': url, 'frob': frob}
return self.auth_getFrob().addCallback(gotFrob)
@@ -299,4 +299,4 @@
elif size == SIZE_LARGE:
suffix = "_b"
-return "http://static.flickr.com/%s/%s_%s%s.jpg"; % (photo.get("server"), photo.get("id"), photo.get("secret"), suffix)
+return "https://static.flickr.com/%s/%s_%s%s.jpg"; % (photo.get("server"), photo.get("id"), photo.get("secret"), suffix)
--- postr-0.13.orig/src/postr.py 2014-06-29 20:52:37.0 +1000
+++ postr-0.13/src/postr.py 2014-06-29 23:26:22.987484867 +1000
@@ -223,11 +223,11 @@
user = client.get_string("/system/http_proxy/authentication_user")
password = client.get_string("/system/http_proxy/authentication_password")
if user and user != "":
-url = "http://%s:%s@%s:%d"; % (user, password, host, port)
+url = "https://%s:%s@%s:%d"; % (user, password, host, port)
else:
-url = "http://%s:%d"; % (host, port)
+url = "https://%s:%d"; % (host, port)
else:
-url = "http://%s:%d"; % (host, port)
+url = "https://%s:%d"; % (host, port)
self.flickr.set_proxy(url)
else:
--- postr-0.13.orig/src/util.py 2014-05-24 05:36:21.0 +1000
+++ postr-0.13/src/util.py 2014-06-29 23:26:29.583536019 +1000
@@ -98,9 +98,9 @@
return load_thumb(page, size)
if int(data.get("iconfarm")) > 0:
-url =
Bug#721303: udisks: breaks LVM and deadlocks LVM related IO to system [SEC=UNCLASSIFIED]
Package: udisks Version: 1.0.4-7 Severity: critical Justification: breaks unrelated software lvm snapshot removal has been broken in debian for a few years now. lvremove has a good chance at any moment to deadlock IO to a box. If you happen to be lucky enough to have dmsetup still in cache, you might be able to resume the device, but more often than not, you simply have no choice but to reboot. Which is kinda bad. /lib/udev/rules.d/80-udisks.rules has the following line in it: KERNEL=="dm-*", OPTIONS+="watch" >From https://www.redhat.com/archives/linux-lvm/2010-August/msg00038.html https://bugzilla.redhat.com/show_bug.cgi?id=577798#c5 we see that you can remove that line, and have reliable lvm again. In fact, rhel6 has a similar kernel to debian wheezy, and has commented that line out all together: # Make udevd synthesize a 'change' uevent when last opener of a rw-fd closes the fd - this # should be part of the device-mapper rules # # Disabled as per #738479 # KERNEL=="dm-*", OPTIONS+="watch" (unfortunately we don't have permission to view rhbz#738479, but I suspect it's just a clone of the fc13 bug 577798) Since I believe this bug directly causes debian bugs: 592250 549691 618016 and probably dozens of others, can we just remove that line in /lib/udev/rules.d/80-udisks.rules like they have in RHEL6 until the real race condition is discovered? Marking as critical, because udisks seems to be pulled in by default on debian, seems to be unnecessary, and most definitely breaks unrelated parts of the system (forced reboots on production systems are bad, mmmkay?) -- System Information: Debian Release: 7.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (5, 'testing'), (1, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages udisks depends on: ii dbus 1.6.8-1+deb7u1 ii libatasmart4 0.19-1 ii libc6 2.13-38 ii libdbus-1-31.6.8-1+deb7u1 ii libdbus-glib-1-2 0.100.2-1 ii libdevmapper1.02.1 2:1.02.74-7 ii libglib2.0-0 2.33.12+really2.32.4-5 ii libgudev-1.0-0 175-7.2 ii liblvm2app2.2 2.02.95-7 ii libparted0debian1 2.3-12 ii libpolkit-gobject-1-0 0.105-3 ii libsgutils2-2 1.33-1 ii libudev0 175-7.2 ii udev 175-7.2 Versions of packages udisks recommends: ii cryptsetup-bin 2:1.4.3-4 ii dosfstools 3.0.13-1 ii eject 2.1.5+deb1+cvs20081104-13 ii hdparm 9.39-1+b1 ii ntfs-3g 1:2012.1.15AR.5-2.1 ii policykit-1 0.105-3 Versions of packages udisks suggests: ii mdadm 3.2.5-5 pn reiserfsprogs pn xfsprogs -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#663200: Bug#659878: cannot set terminal process group (-1): Inappropriate ioctl for device
On Fri, 10 May 2013, Tim Connors wrote: > Actually, the other thing you lose (I presuming caused by acting on bug > #628843) is tty resizing by SIGWINCH. ttys are really useful, it turns > out. > > I have shedloads of up-to-date security patched RHEL5/6 machines, and I've > never come across this problem on them. Yep: > rhel6> su -c -u root 'cat /dev/tty' > Password: > asdasda > asdasda > debian-wheezy> su -c -u root 'cat /dev/tty' > Password: > cat: /dev/tty: No such device or address > > Sorry, marking this bug as RC (pity I missed wheezy!), breaks other > software. As per some comments in #628843, the way this bug was addressed breaks su -c to increase privledges. It also breaks su -c to become a user and execute something interactive. Root isn't going to be doing stupid things and running scripts that have been compromised (if they are, then they've got bigger problems), so what's the problem? (why on earth would root ever su to an untrusted user account?) I think this change should just be backed out, and a prominent warning about the tty exploit placed in the manpage. -- Tim Connors -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#612313: open-vm-source: does not compile on squeeze kernels 2.6.32
Package: open-vm-source Version: 1:8.4.2-261024-1 Severity: critical I need the vmxnet module since we only have ESXi 3.5 here, but open-vm-source won't compile with the squeeze kernel: QUILT_PATCHES=debian/patches \ quilt --quiltrc /dev/null pop -a -R || test $? = 2 rm -rf .pc debian/stamp-patched dh_testdir dh_testroot rm -f build-stamp rm -f config/config.guess config/config.sub # Cleaning package [ ! -f Makefile ] || /usr/bin/make distclean make[1]: Entering directory `/usr/src/modules/open-vm' /usr/bin/make OVT_SOURCE_DIR=/usr/src/modules/open-vm -C modules/linux/pvscsi clean make[2]: Entering directory `/usr/src/modules/open-vm/modules/linux/pvscsi' rm -rf pvscsi.mod.c pvscsi.ko .tmp_versions Module.symvers modules.order ./.pvscsi.ko.cmd ./.pvscsi.mod.o.cmd ./.pvscsi.o.cmd ./pvscsi.mod.o ./pvscsi.o make[2]: Leaving directory `/usr/src/modules/open-vm/modules/linux/pvscsi' /usr/bin/make OVT_SOURCE_DIR=/usr/src/modules/open-vm -C modules/linux/vmblock clean make[2]: Entering directory `/usr/src/modules/open-vm/modules/linux/vmblock' rm -rf vmblock.mod.c vmblock.ko .tmp_versions Module.symvers modules.order ./.vmblock.ko.cmd ./.vmblock.mod.o.cmd ./.vmblock.o.cmd ./vmblock.mod.o ./vmblock.o linux/.block.o.cmd linux/.control.o.cmd linux/.dbllnklst.o.cmd linux/.dentry.o.cmd linux/.file.o.cmd linux/.filesystem.o.cmd linux/.inode.o.cmd linux/.module.o.cmd linux/.stubs.o.cmd linux/.super.o.cmd linux/block.o linux/control.o linux/dbllnklst.o linux/dentry.o linux/file.o linux/filesystem.o linux/inode.o linux/module.o linux/stubs.o linux/super.o make[2]: Leaving directory `/usr/src/modules/open-vm/modules/linux/vmblock' /usr/bin/make OVT_SOURCE_DIR=/usr/src/modules/open-vm -C modules/linux/vmci clean make[2]: Entering directory `/usr/src/modules/open-vm/modules/linux/vmci' rm -rf .tmp_versions ./.kernelStubsLinux.o.cmd ./kernelStubsLinux.o make[2]: Leaving directory `/usr/src/modules/open-vm/modules/linux/vmci' rm -f modules/linux/vmhgfs/Module.symvers /usr/bin/make OVT_SOURCE_DIR=/usr/src/modules/open-vm -C modules/linux/vmhgfs clean make[2]: Entering directory `/usr/src/modules/open-vm/modules/linux/vmhgfs' rm -rf make[2]: Leaving directory `/usr/src/modules/open-vm/modules/linux/vmhgfs' /usr/bin/make OVT_SOURCE_DIR=/usr/src/modules/open-vm -C modules/linux/vmmemctl clean make[2]: Entering directory `/usr/src/modules/open-vm/modules/linux/vmmemctl' rm -rf make[2]: Leaving directory `/usr/src/modules/open-vm/modules/linux/vmmemctl' /usr/bin/make OVT_SOURCE_DIR=/usr/src/modules/open-vm -C modules/linux/vmsync clean make[2]: Entering directory `/usr/src/modules/open-vm/modules/linux/vmsync' rm -rf make[2]: Leaving directory `/usr/src/modules/open-vm/modules/linux/vmsync' /usr/bin/make OVT_SOURCE_DIR=/usr/src/modules/open-vm -C modules/linux/vmxnet clean make[2]: Entering directory `/usr/src/modules/open-vm/modules/linux/vmxnet' rm -rf make[2]: Leaving directory `/usr/src/modules/open-vm/modules/linux/vmxnet' /usr/bin/make OVT_SOURCE_DIR=/usr/src/modules/open-vm -C modules/linux/vmxnet3 clean make[2]: Entering directory `/usr/src/modules/open-vm/modules/linux/vmxnet3' rm -rf make[2]: Leaving directory `/usr/src/modules/open-vm/modules/linux/vmxnet3' rm -f modules/linux/vsock/Module.symvers /usr/bin/make OVT_SOURCE_DIR=/usr/src/modules/open-vm -C modules/linux/vsock clean make[2]: Entering directory `/usr/src/modules/open-vm/modules/linux/vsock' rm -rf make[2]: Leaving directory `/usr/src/modules/open-vm/modules/linux/vsock' make[1]: Leaving directory `/usr/src/modules/open-vm' dh_clean /usr/bin/make KERNELDIR=/lib/modules/2.6.32-5-amd64/build clean make[1]: Entering directory `/usr/src/modules/open-vm' /usr/bin/make OVT_SOURCE_DIR=/usr/src/modules/open-vm -C modules/linux/pvscsi clean make[2]: Entering directory `/usr/src/modules/open-vm/modules/linux/pvscsi' rm -rf make[2]: Leaving directory `/usr/src/modules/open-vm/modules/linux/pvscsi' /usr/bin/make OVT_SOURCE_DIR=/usr/src/modules/open-vm -C modules/linux/vmblock clean make[2]: Entering directory `/usr/src/modules/open-vm/modules/linux/vmblock' rm -rf make[2]: Leaving directory `/usr/src/modules/open-vm/modules/linux/vmblock' /usr/bin/make OVT_SOURCE_DIR=/usr/src/modules/open-vm -C modules/linux/vmci clean make[2]: Entering directory `/usr/src/modules/open-vm/modules/linux/vmci' rm -rf make[2]: Leaving directory `/usr/src/modules/open-vm/modules/linux/vmci' rm -f modules/linux/vmhgfs/Module.symvers /usr/bin/make OVT_SOURCE_DIR=/usr/src/modules/open-vm -C modules/linux/vmhgfs clean make[2]: Entering directory `/usr/src/modules/open-vm/modules/linux/vmhgfs' rm -rf make[2]: Leaving directory `/usr/src/modules/open-vm/modules/linux/vmhgfs' /usr/bin/make OVT_SOURCE_DIR=/usr/src/modules/open-vm -C modules/linux/vmmemctl clean make[2]: Entering directory `/usr/src/modules/open-vm/modules/linux/vmmemctl' rm -rf make[2]: Leaving directory `/usr/src/modules/open-vm/modules/linux/vmmemctl' /usr/bin/make OVT_SOURCE_DIR=/
Bug#604993: dash as /bin/sh causes $PPID to be wrong in child when invoked via system() call
Package: dash
Version: 0.5.5.1-7.2
Severity: grave
Any calls to system() invokes
sh -c
When /bin/sh is linked to dash, if is a shell script (/bin/sh
or /bin/bash), that shell script sees $PPID as being the "sh -c" process.
If /bin/sh is linked to bash, sees $PPID as being the actual
parent, which is a hell of a lot more useful (and in my case, required
for functionality of scripts I wrote a long time ago and I believe are
acting correctly).
My suspicion is that dash is doing an extra fork before exec, which
seems entirely useless, and not exactly in keeping with the
"lightweight and fast" aims of dash (forks can be expensive - glad
I don't have dash installed on our slowaris boxes!).
I think I can confirm this with this simple example:
75318,3> perl -e 'system("/bin/bash -c \"sleep 60\"");'
75319,7> ps axuf | grep -A5 perl.*[s]ystem
twc 19561 0.0 0.0 20132 1676 pts/118 S+ 13:49 0:00
\_ perl -e system("/bin/bash -c \"sleep 60\"");
twc 19562 0.0 0.0 9512 616 pts/118 S+ 13:49 0:00
\_ sleep 60
75320,5> perl -e 'system("/bin/dash -c \"sleep 60\"");'
75320,8> ps axuf | grep -A5 perl.*[s]ystem
twc 19752 0.0 0.0 20132 1676 pts/118 S+ 13:49 0:00
\_ perl -e system("/bin/dash -c \"sleep 60\"");
twc 19753 0.0 0.0 8104 632 pts/118 S+ 13:49 0:00
\_ /bin/dash -c sleep 60
twc 19754 0.0 0.0 9512 616 pts/118 S+ 13:49 0:00
\_ sleep 60
I have marked this as "grave", because it breaks unrelated parts of
the system: Sure, it's a shell script using /bin/sh (linked to dash)
that broke in this case, but anyone is free to use $PPID (via
/proc/.../status), and all it took was for the job of "sh -c" (that
system() always uses) having been taken over by the dash package
instead of bash. Never mind the fact that I didn't actively install
dash - it came in with dependencies and eventually decided to ignore
my choice for /bin/sh to be manually linked to bash after several
upgrades where it obeyed me).
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages dash depends on:
ii debianutils 3.4Miscellaneous utilities specific t
ii dpkg 1.15.8.5 Debian package management system
ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib
dash recommends no packages.
dash suggests no packages.
-- debconf information:
* dash/sh: true
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#596630: disk full leads to xauth nulling out the Xauthority file completely instead of just failing to create entry
Package: xauth Version: 1:1.0.3-2 Severity: grave Justification: causes non-serious data loss If I have a non zero ~/.Xauthority file, then create a file in my home directory that fills the disk, and ssh in again (not closing the original X or ssh session so the Xauthority entries for those are still valid and have not been removed), something somewhere between ssh and libxcb completely empties ~/.Xauthority (silently! No error logged to stderr!). Smacks of just trying to rewrite a file without using a temporary file, or not checking for any errors of the write() or close() before running rename(), doesn't it? -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-bpo.4-686 (SMP w/1 CPU core) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xauth depends on: ii libc6 2.7-18lenny2 GNU C Library: Shared libraries ii libx11-62:1.1.5-2X11 client-side library ii libxau6 1:1.0.3-3X11 authorisation library ii libxext62:1.0.4-1X11 miscellaneous extension librar ii libxmuu12:1.0.4-1X11 miscellaneous micro-utility li ii x11-common 1:7.3+20 X Window System (X.Org) infrastruc xauth recommends no packages. xauth suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#526409: [Evolution] Bug#526409: evolution: permissions on mailbox folders are set wrong
On Mon, 4 May 2009, Yves-Alexis Perez wrote:
> On ven, 2009-05-01 at 11:25 +1000, Tim Connors wrote:
> > Package: evolution
> > Version: 2.24.5-3
> > Severity: grave
> > Tags: security
> > Justification: user security hole
> >
> > tconn...@denman:~$ l /home/maree/.evolution/mail/local/Sent
> > -rw-r--r-- 1 maree maree 118474734 2009-05-01 08:16
> > /home/maree/.evolution/mail/local/Sent
> >
> > Hmmm. Would it be a good idea to set ~/.evolution to 700 perhaps? Or
> > just adopt a restrictive umask for the whole of evolution (mail being
> > a rather more sensitive application than most)?
> >
> > Many site policies are for home directories to be world or group
> > readable, and trusting users not to be stupid with their permissions.
> > Unfortunately this breaks down when the applications themselves are
> > stupid.
> >
> > This affects upstream as well, as verified by several installations of
> > deadrat and the like installed over many years at work.
>
> Are you saying that if you change .evolution permissions to 700, they
> are set back to 744 after evolution run? Because they aren't here.
>
> If you say that evolution should create folder/files with more
> restrictive defaults, I disagree.
Yes, I'm saying they should be created with more restrictive defaults.
> evolution should just use what the
> current umask is. If you want it to another value, just set it in you
> environment before running evolution (isn't that the purpose of umask
> anyway?). Multi-user systems running evolution aren't that frequent, I
> guess (multi-user systems aren't that frequent anyway, these days) and
> you can adjust the permissions for your ~ and .evolution in a lot of
> different ways. No need to add complexity to that huge stack of code.
Family machines? (eg, the machine I found this bug on. I myself wouldn't
use evolution or indeed desktop environments if I was forced at gunpoint,
but that's what mum uses. In desktop environments, good luck setting a
sensible umask.)
What kind of complexity is
int main(...) {
umask(0700);
...
}
?
Since mail (and web browser profiles - I believe firefox does this, and
opera certainly does) is about the only thing of this kind of sensitivity,
it should explicitly set mail permissions.
More sensible MTAs like alpine and mutt do this (indeed, alpine warns you
if you have silly permissions).
--
TimC
Dijkstra probably hates me
(Linus Torvalds, on gotos in kernel/sched.c)
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#526409: evolution: permissions on mailbox folders are set wrong
Package: evolution Version: 2.24.5-3 Severity: grave Tags: security Justification: user security hole tconn...@denman:~$ l /home/maree/.evolution/mail/local/Sent -rw-r--r-- 1 maree maree 118474734 2009-05-01 08:16 /home/maree/.evolution/mail/local/Sent Hmmm. Would it be a good idea to set ~/.evolution to 700 perhaps? Or just adopt a restrictive umask for the whole of evolution (mail being a rather more sensitive application than most)? Many site policies are for home directories to be world or group readable, and trusting users not to be stupid with their permissions. Unfortunately this breaks down when the applications themselves are stupid. This affects upstream as well, as verified by several installations of deadrat and the like installed over many years at work. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (710, 'testing'), (700, 'stable'), (600, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages evolution depends on: ii dbus 1.2.12-1simple interprocess messaging syst ii debconf [debconf 1.5.26 Debian configuration management sy ii evolution-common 2.24.5-3architecture independent files for ii evolution-data-s 2.24.5-4+b1 evolution database backend server ii gconf2 2.24.0-7GNOME configuration database syste ii gnome-icon-theme 2.24.0-4GNOME Desktop icon theme ii libart-2.0-2 2.3.20-2Library of functions for 2D graphi ii libatk1.0-0 1.24.0-2The ATK accessibility toolkit ii libbluetooth23.36-1 Library to use the BlueZ Linux Blu ii libbonobo2-0 2.24.1-1Bonobo CORBA interfaces library ii libbonoboui2-0 2.24.1-1The Bonobo UI library ii libc62.9-6 GNU C Library: Shared libraries ii libcairo21.8.6-2+b1 The Cairo 2D vector graphics libra ii libcamel1.2-14 2.24.5-4+b1 The Evolution MIME message handlin ii libdbus-1-3 1.2.12-1simple interprocess messaging syst ii libdbus-glib-1-2 0.80-3 simple interprocess messaging syst ii libebackend1.2-0 2.24.5-4+b1 Utility library for evolution data ii libebook1.2-92.24.5-4+b1 Client library for evolution addre ii libecal1.2-7 2.24.5-4+b1 Client library for evolution calen ii libedataserver1. 2.24.5-4+b1 Utility library for evolution data ii libedataserverui 2.24.5-4+b1 GUI utility library for evolution ii libegroupwise1.2 2.24.5-4+b1 Client library for accessing group ii libenchant1c2a 1.4.2-3.3 a wrapper library for various spel ii libexchange-stor 2.24.5-4+b1 Client library for accessing Excha ii libfontconfig1 2.6.0-3 generic font configuration library ii libfreetype6 2.3.9-4 FreeType 2 font engine, shared lib ii libgconf2-4 2.24.0-7GNOME configuration database syste ii libgdata-google1 2.24.5-4+b1 Client library for accessing Googl ii libgdata1.2-12.24.5-4+b1 Client library for accessing Googl ii libglade2-0 1:2.6.3-1 library to load .glade files at ru ii libglib2.0-0 2.20.0-2The GLib library of C routines ii libgnome-pilot2 2.0.15-2.4 Support libraries for gnome-pilot ii libgnome2-0 2.24.1-2The GNOME 2 library - runtime file ii libgnomecanvas2- 2.20.1.1-1 A powerful object-oriented display ii libgnomeui-0 2.24.1-1The GNOME 2 libraries (User Interf ii libgnomevfs2-0 1:2.24.1-1 GNOME Virtual File System (runtime ii libgtk2.0-0 2.14.7-5The GTK+ graphical user interface ii libgtkhtml-edito 3.24.5-2HTML rendering/editing library - e ii libgtkhtml3.14-1 3.24.5-2HTML rendering/editing library - r ii libhal1 0.5.11-8Hardware Abstraction Layer - share ii libice6 2:1.0.5-1 X11 Inter-Client Exchange library ii libldap-2.4-22.4.15-1OpenLDAP libraries ii libnm-glib0 0.7.0.100-1 network management framework (GLib ii libnotify1 [libn 0.4.5-1 sends desktop notifications to a n ii libnspr4-0d 4.7.1-4 NetScape Portable Runtime Library ii libnss3-1d 3.12.2.with.ckbi.1.73-1 Network Security Service libraries ii liborbit21:2.14.17-0.1 libraries for ORBit2 - a CORBA ORB ii libpango1.0-01.24.0-3Layout and rendering of internatio ii libpisock9 0.12.3-10 library for communicating with
Bug#509404: openoffice.org-common: dpkg can't configure because of dico_checkroot
On Mon, 22 Dec 2008, Rene Engelhard wrote: > Hi, > > Tim Connors wrote: > > it updates fine, and dist-upgrade finally works. > > >From what to what? Both a test dist-upgrade etch->lenny and lenny->sid > do work for me. sid-sid, somewhere between dec 1 and dec 19, ie, when there were no dictionaries-common changes. -- TimC I've told them and told them: Temporal anomalies are different from spatial anomalies. But the kittens know better. They laugh at my feeble attempts to fool them. -- barbara in ARK -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#509404: openoffice.org-common: dpkg can't configure because of dico_checkroot
On Mon, 22 Dec 2008, Rene Engelhard wrote: > tag 509404 + unreproducible > tag 509404 + moreinfo > thanks > > Rene Engelhard wrote: > > Tim Connors wrote: > > > I can't configure openoffice.org-common, either with the version in > > > testing (1:2.4.1-14), or with unstable (1:2.4.1-15, and the dependencies): > > > > > > Setting up openoffice.org-common (1:2.4.1-14) ... > > > "dico_checkroot" is not exported by the Debian::DictionariesCommon module > > > Can't continue after import errors at /usr/sbin/update-openoffice-dicts > > > line 9 > > ^ > > > BEGIN failed--compilation aborted at /usr/sbin/update-openoffice-dicts > > > line 9. > > > dpkg: error processing openoffice.org-common (--configure): > > > subprocess post-installation script returned error exit status 9 > > > > If at all, this is (obviously) is a dictionaries-common bug > > (openoffice.org-common > > runs update-openoffice-dicts, and guess where that script is? right :-)): > > Needless to say, I can't reproduce this: > > r...@mini:~$ sudo update-openoffice-dicts > Updating OpenOffice.org's dictionary list... done. That's certainly peculiar. If I run $ sudo update-openoffice-dicts it updates fine, and dist-upgrade finally works. Might make tracking down the bug more difficult though, since it's now installed and configured. -- TimC If my head were spinning at relativistic speeds, it would appear to everyone else that my brane had slowed down. -- Dan E. Macs on RHOD -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#509404: openoffice.org-common: dpkg can't configure because of dico_checkroot
Package: openoffice.org-common Version: 1:2.4.1-14 Severity: grave Justification: renders package unusable I can't configure openoffice.org-common, either with the version in testing (1:2.4.1-14), or with unstable (1:2.4.1-15, and the dependencies): Setting up openoffice.org-common (1:2.4.1-14) ... "dico_checkroot" is not exported by the Debian::DictionariesCommon module Can't continue after import errors at /usr/sbin/update-openoffice-dicts line 9 BEGIN failed--compilation aborted at /usr/sbin/update-openoffice-dicts line 9. dpkg: error processing openoffice.org-common (--configure): subprocess post-installation script returned error exit status 9 -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages openoffice.org-common depends on: ii dictionaries-common [openoffi 0.98.12Common utilities for spelling dict ii openoffice.org-style-andromed 1:2.4.1-14 Default symbol style for OpenOffic Versions of packages openoffice.org-common recommends: pn openoffice.org-style-crystal (no description available) pn openoffice.org-style-tango (no description available) Versions of packages openoffice.org-common suggests: pn openoffice.org-style-hicontra (no description available) pn openoffice.org-style-industri (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#491394: acpid causes CPUfreq to be limited to 800MHz - 800Mhz
Package: acpid Version: 1.0.6-10 Severity: grave Justification: renders package unusable Even with hal turned off and gnome-power and all that crap not being installed, I have up until recently had laptop-mode-tools as the sole controller of my laptop's power management. laptop_mode is of course controlled through /etc/acpi/actions/lm_*. Lately, something has been limiting my CPU to 800Mhz only, when I go to battery: AC: > cpufreq-info | grep 'should be within' current policy: frequency should be within 800 MHz and 2.20 GHz. battery: > cpufreq-info | grep 'should be within' current policy: frequency should be within 800 MHz and 800 MHz. The CPU governor remains on ondemand. If I disable the calls to lm_* within the acpi directory, or if I tell laptop_mode to not touch anything CPU related (despite it being configged not to limit the CPU in such fashion), and even if I uninstall it, something is still telling the CPU to limit to 800MHz. So it's not laptop_mode. I don't have other cpufreq related tools installed (except cpufrequtils, which doesn't run anything that might change the governor behaviour on the fly). If I remove the acpi directory, then the goveror is still changed. If I stop the acpid daemon, then the govenor *isn't* changed. As I can't see anything else being run by acpid, it must therefore be acpi itself at fault, do you agree? Is there anything new that acpid is doing behind our back to change the CPU goveronr? Below, I show the order of events - first I generate an strace output on acpi, tail the strace output once things have settled down, unplug the laptop and terminate the logging once acpi has started polling for the next acpi event: 0-0-12:49:26, Fri Jul 18 [EMAIL PROTECTED]:/etc/acpi (bash) 51307,131> strace -o /tmp/acpi.txt -f /etc/init.d/acpid restart 0-0-13:03:26, Fri Jul 18 [EMAIL PROTECTED]:/home/tconnors (bash) > cpufreq-info | grep 'should be within' current policy: frequency should be within 800 MHz and 2.20 GHz. current policy: frequency should be within 800 MHz and 2.20 GHz. 0-0-13:03:38, Fri Jul 18 [EMAIL PROTECTED]:/home/tconnors (bash) 51301,42> tail -f /tmp/acpi.txt > /tmp/acpi-to-batt ### #unplug laptop here, and wait a bit ### ^C 130-0-13:03:50, Fri Jul 18 [EMAIL PROTECTED]:/home/tconnors (bash) 51302,43> cpufreq-info | grep 'should be within' current policy: frequency should be within 800 MHz and 800 MHz. current policy: frequency should be within 800 MHz and 800 MHz. The 330K of strace output has been placed on my webserver: http://rather.puzzling.org/~tconnors/tmp/acpi-to-batt I can't see anything incriminating in there, but since disabling acpi is sufficient to stop this happening, it must be in there somewhere... -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25 (SMP w/2 CPU cores) Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages acpid depends on: ii libc6 2.7-12 GNU C Library: Shared libraries ii lsb-base 3.2-15 Linux Standard Base 3.2 init scrip ii module-init-tools 3.4-1 tools for managing Linux kernel mo acpid recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#459041: xterm: version 230-1 segfaults somewhere when involving cut and paste
Package: xterm Version: 230-1 Severity: grave Justification: causes non-serious data loss Cutting text somewhere in an xterm causes it to segfault with the most recent upgrade. It may involve either the cut or paste of long lines. I'm pretty sure it happens as soon as I click the mouse to make a selection, and can happen after a successful cut and paste or two. I haven't yet restarted X, but that's not going to cause a dynamic library inconsistency problem. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.23 (SMP w/2 CPU cores) Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages xterm depends on: ii libc6 2.7-5 GNU C Library: Shared libraries ii libfontconfig12.5.0-2generic font configuration library ii libice6 2:1.0.4-1 X11 Inter-Client Exchange library ii libncurses5 5.6+20071215-1 Shared libraries for terminal hand ii libsm62:1.0.3-1+b1 X11 Session Management library ii libx11-6 2:1.0.3-7 X11 client-side library ii libxaw7 2:1.0.4-1 X11 Athena Widget library ii libxext6 1:1.0.3-2 X11 miscellaneous extension librar ii libxft2 2.1.12-2 FreeType-based font drawing librar ii libxmu6 1:1.0.3-1 X11 miscellaneous utility library ii libxt61:1.0.5-3 X11 toolkit intrinsics library ii xbitmaps 1.0.1-2Base X bitmaps Versions of packages xterm recommends: ii xutils1:7.3+9X Window System utility programs m -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457828: chkrootkit: Killing a random PID with an arbitrary signal to test whether it is a trojan is extremely unpolite
Package: chkrootkit Version: 0.47-1.1 Severity: critical Justification: breaks unrelated software In testing for the Enye LKM, chkrootkit sends signal 58 to PID 12345. This has a chance of hitting any one process of 1/32767. On the system I am typing this on in its current state, I have 350 processes running, and it is not currently busy, so that's 1/100 chance of hitting a process by random. If the system is up for a while, and I run chkrootkit in a daily cronjob, I can expect a random process to be sent signal 58 once every 100 days or so. The other day, it killed gnuplot_x11, which I only noticed once I read my mail saying chkrootkit had "Enye LKM found". It certainly explained why a script of mine got confused, and I could tell it had killed gnuplot_x11 because it was still in a zombie state, having not yet been reaped by gnuplot, and it was running as pid 12345. There are reports on the net of it killing other processes. That signal number is not documented in 'man 7 signal', so I guess it's not likely anything would install a signal handler than could deal with 58. Presumably chkrootkit is hoping that signal would be rejected by the kernel as invalid, but that assumption is invalid today: $ sleep 1000 & [1] 19277 $ kill -58 19277 [1]+ Real-time signal 24 sleep 1000 $ Incidentally, the documentation of the tests in chkproc.c needs a lot of work: 'man 2 kill' doesn't describe kill as ever being able to return a positive error value, but of course it must, because I got the "Enye LKM found" message. It took me a while to work out that that code was trying to do anything other than detect for the presence of pid 12345. Perhaps the signals it is sending could be better documented, as to the test for the error return value, and indeed the prevous test for the Adobe LKM, using an errno magic number instead of symbolic name. And why it sends signal 100 to init first without testing the result. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.23 (SMP w/2 CPU cores) Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages chkrootkit depends on: ii binutils2.18.1~cvs20071027-2 The GNU assembler, linker and bina ii debconf [debconf-2. 1.5.17 Debian configuration management sy ii libc6 2.7-5GNU C Library: Shared libraries ii net-tools 1.60-19 The NET-3 networking toolkit ii procps 1:3.2.7-5/proc file system utilities chkrootkit recommends no packages. -- debconf information: chkrootkit/run_daily: false chkrootkit/run_daily_opts: -q chkrootkit/diff_mode: false -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400329: wwwoffle: lock-files in concurrent downloading broken either way
Package: wwwoffle Version: 2.9-2 Severity: grave Justification: causes non-serious data loss wwwoffle has the setting: # lock-files = yes | no # Enable the use of lock files to stop more than one WWWOFFLE process # from downloading the same URL at the same time (default=no). Either way this is set, it is broken. If set to yes, it seems that a lockfile only manages to tell the second process to give up loading the page at all, giving back a HTTP 500 WWWOFFLE Server Error: > for i in `seq 1 10 ` ;do lynx -dump http://www.google.com.au & done WWWOFFLE - World Wide Web Offline Explorer - v2.9 _ WWWOFFLE Server Error The WWWOFFLE server encountered a fatal error: Cannot open the spooled web page to read. The program cannot continue to service this request. Help This is an internal WWWOFFLE server error that should not occur. There is no other way of handling the error apart from providing this warning page. If this error continues and WWWOFFLE is configured correctly and there are no other computer problems then you should report the error to the WWWOFFLE author. _ WWWOFFLE - [[1]Welcome Page|[2]FAQ] - WWWOFFLE References 1. http://scuzzie:8080/Welcome.html 2. http://scuzzie:8080/FAQ.html ... By loading many pages at once as above, some of them end up succeeding after the cache has been loaded, but prior to that, all but one of them are going to fail -- above I'd see 5 or so error pages, then 5 or so successful downloads -- YMW(ill)V as my computer is probably slow enough for this test to come out this way. If set to no, then the first process to hit the cache gets their download, but the second process only retrieves as much as had reached the first process at that time. So the second download ends up incomplete. No error is returned, so it may not even be apparent until a later date -- hence dataloss. Marked as grave because of dataloss, since any webpage using crappy session management, or submition of forms, etc, ends up being broken whenever the page is being concurrently loaded in two seperate pages/processes with either setting, and one copy will not be complete or will fail altogether. Most of the rest of the time, a reload ought to fix it, but this sometimes ends up loading from the browser's own cache, which has only been half downloaded (I can't seem to convince opera to drop its version of its cache, and reload from the proxy) -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-1-686 Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1) Versions of packages wwwoffle depends on: ii coreutils5.97-5.2The GNU core utilities ii debconf [debconf-2.0]1.5.9 Debian configuration management sy ii debianutils 2.17.3 Miscellaneous utilities specific t ii libc62.3.6.ds1-8 GNU C Library: Shared libraries ii zlib1g 1:1.2.3-13 compression library - runtime wwwoffle recommends no packages. -- debconf information: * wwwoffle/string_port_number: 8080 wwwoffle/ageline_added: wwwoffle/use-htdig: false wwwoffle/ppp-fetch: true * wwwoffle/use-ppp-interface: false wwwoffle/ageline_lost: wwwoffle/text_new_location: wwwoffle/conf-perm: * wwwoffle/string_parent_proxy: none * wwwoffle/select_html_lang: en (English) wwwoffle/ipv6defaultnone: * wwwoffle/fetchfrequency: off wwwoffle/note_upgrade_config_failed: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#333479: gdk-imlib1: gdk-imblib1 should not explicitly conflict with libpng2
Thomas Bushnell BSG <[EMAIL PROTECTED]> Date: Tue, 11 Oct 2005 23:50:44 -0700: > Ron <[EMAIL PROTECTED]> writes: > >> Package: gdk-imlib1 >> Version: 1.9.14-22 >> Severity: critical >> Justification: breaks unrelated software >> >> Unless there is something big I am missing, gdk-imlib should >> certainly not take it upon itself to force the removal of >> libpng2 and all its dependencies... > > There is something big you are missing. > > libpng2 is being removed from Debian. libpng12-0 is a suitable > replacement, source and binary compatible. Doesn't seem to be binary compatible at all. Shoot me for using a closed sourced app, but xv doesn't like me symlinking /usr/lib/libpng.so.2 to /usr/lib/libpng12.so, but copes fine with libpng10.so For now, I've just manually copied the old libpng10.so over, and let dpkg get rid of libpng10, since I don't think I am running any apps that run both gdk-imlib1 and libpng2 simultaneously. Why, instead of conflicting, couldn't you simply let apps that depend on both to segfault, as you say, and then let users submit bugs to the app in question that needs to be rebuilt anyway, instead of throwing out the baby with the bathwater? You seem to justify that this saves apps from outside debian from breaking, but it breaks xv. -- TimC "The Write Many, Read Never drive. For those people that don't know their system has a /dev/null already." -- Rik Steenwinkel, singing the praises of 8mm Exabytes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#320115: qiv: background setting in bug #294293 causes X session to become useless
Package: qiv Version: 2.0-3 Severity: grave Justification: causes non-serious data loss I tried to reopen 294293, but obviously don't know how to do this correctly... This causes major breakage in case of fullscreen (you can't destroy a window when it is the root window!) - renders the X session useless (see bug 197335). I am marking this grave, because causing the loss of an X session is data loss. This bug may well have been there in previous versions of qiv, but it was hidden - I have pressed y many a time (accidentally and not), and gotten a background on my root window (using fvwm, not gnome), and it worked just fine. Now, if I or one of my cats accidentally press 'y', then I am stuffed. I *really* don't like losing my X session to a window that can't be moved or lowered or closed or destroyed. I have verified that I can go back to version 2.0-3, and the problem disappears. I am using Xorg currently, but the problem also existed under Xfree86. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.31 Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1) Versions of packages qiv depends on: ii gdk-imlib11.9.14-16.2imaging library for use with gtk ( ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libglib1.21.2.10-10 The GLib library of C routines ii libgtk1.2 1.2.10-17 The GIMP Toolkit set of widgets fo ii libx11-6 6.8.2.dfsg.1-4 X Window System protocol client li ii libxext6 6.8.2.dfsg.1-4 X Window System miscellaneous exte ii libxi66.8.2.dfsg.1-4 X Window System Input extension li ii xlibs 6.8.2.dfsg.1-4 X Window System client libraries m qiv recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#312853: apt-listbugs: apt{itude,-get} upgrade: dies with "...not in gzip format..."
Package: apt-listbugs Version: 0.0.49 Severity: grave Justification: renders package unusable I have no idea where to assign this to, but it looks like apt-listbugs. I just tried to upgrade via aptitude, and it bombed out: Get:7 http://mirror.aarnet.edu.au unstable/main libgnomecanvas2-0 2.10.2-2 [103kB] Get:8 http://mirror.aarnet.edu.au unstable/main libgnomecanvas2-common 2.10.2-2 [125kB] Fetched 2816kB in 25s (110kB/s) Reading package fields... Done Reading package status... Done Retrieving bug reports... 0% [0/40] W: not in gzip format: kernel-patch-scripts W: not in gzip format: dbus-1 W: not in gzip format: findutils W: not in gzip format: libgnomecanvas2-0 W: not in gzip format: libgnome2-common W: not in gzip format: libgnomevfs2-0 W: not in gzip format: libgnomecanvas2-common W: not in gzip format: gcc-4.0-base W: not in gzip format: clusterssh ... E: Too many errors while retrieving bug reports E: Sub-process if dpkg -s apt-listbugs | grep -q '^Status: .* ok installed'; then /usr/sbin/apt-listbugs apt || ( test $? -ne 10 || exit 10; echo 'Warning: apt-listbugs exited abnormally, hit enter key to continue.' 1>&2 ; read a < /dev/tty ); fi returned an error code (10) E: Failure running script if dpkg -s apt-listbugs | grep -q '^Status: .* ok installed'; then /usr/sbin/apt-listbugs apt || ( test $? -ne 10 || exit 10; echo 'Warning: apt-listbugs exited abnormally, hit enter key to continue.' 1>&2 ; read a < /dev/tty ); fi Ack! Something bad happened while installing packages. Trying to recover: Reading Package Lists... Done Building Dependency Tree Reading extended state information Initializing package states... Done # Trying to upgrade fewer packages at a time works though. Perhaps apt-listbugs should not return a non-zero exit code if an error occurred - only if the user said "don't continue" (if that is indeed how apt-listbugs works), since otherwise it renders the system un-upgradable? -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.26 Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1) Versions of packages apt-listbugs depends on: ii apt 0.5.28.6 Advanced front-end for dpkg ii libdpkg-ruby1.8 0.3.1 modules/classes for dpkg on ruby 1 ii libintl-gettext-ruby1.8 0.11-5 Gettext wrapper for Ruby 1.8 ii libruby1.8 [libzlib-ruby1.8] 1.8.2-7Libraries necessary to run Ruby 1. ii libxml-parser-ruby1.8 0.6.8-1Interface of expat for the scripti ii ruby 1.8.2-1An interpreter of object-oriented -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
