Bug#768650: mtr: use setcap instead of setuid to reduce security attack surface
Package: mtr
Tags: patch, security
This seems to have been fairly successful for iputils, so let's do it
more. The attached patch causes mtr and mtr-tiny to be installed with
a file capability for CAP_NET_RAW instead of being setuid root, which
substantially reduces their privileges. I've shamelessly copied the
postinst script from iputils (noahm++).
diff --git a/debian/control b/debian/control
index be35beb..42515c7 100644
--- a/debian/control
+++ b/debian/control
@@ -9,7 +9,7 @@ Build-Depends: libncurses-dev, debhelper (= 5), libgtk2.0-dev, automake
Package: mtr
Architecture: any
Priority: extra
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}, libcap2-bin
Conflicts: suidmanager ( 0.50), mtr-tiny
Replaces: mtr-tiny
Description: Full screen ncurses and X11 traceroute tool
@@ -26,7 +26,7 @@ Description: Full screen ncurses and X11 traceroute tool
Package: mtr-tiny
Architecture: any
Priority: optional
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends}, libcap2-bin
Conflicts: suidmanager ( 0.50), mtr
Replaces: mtr
Description: Full screen ncurses traceroute tool
diff --git a/debian/mtr-tiny.postinst b/debian/mtr-tiny.postinst
new file mode 100644
index 000..f72e35b
--- /dev/null
+++ b/debian/mtr-tiny.postinst
@@ -0,0 +1,22 @@
+#!/bin/sh
+
+set -e
+
+if [ $1 = configure ]; then
+# If we have setcap is installed, try setting cap_net_raw+ep,
+# which allows us to install our binaries without the setuid
+# bit.
+if command -v setcap /dev/null; then
+if ! setcap cap_net_raw+ep /usr/bin/mtr-tiny; then
+echo Setcap failed on /usr/bin/mtr-tiny, falling back to setuid 2
+chmod u+s /usr/bin/mtr-tiny
+fi
+else
+echo Setcap is not installed, falling back to setuid 2
+chmod u+s /usr/bin/mtr-tiny
+fi
+fi
+
+#DEBHELPER#
+
+exit 0
diff --git a/debian/mtr.postinst b/debian/mtr.postinst
new file mode 100644
index 000..13fb00e
--- /dev/null
+++ b/debian/mtr.postinst
@@ -0,0 +1,22 @@
+#!/bin/sh
+
+set -e
+
+if [ $1 = configure ]; then
+# If we have setcap is installed, try setting cap_net_raw+ep,
+# which allows us to install our binaries without the setuid
+# bit.
+if command -v setcap /dev/null; then
+if ! setcap cap_net_raw+ep /usr/bin/mtr; then
+echo Setcap failed on /usr/bin/mtr, falling back to setuid 2
+chmod u+s /usr/bin/mtr
+fi
+else
+echo Setcap is not installed, falling back to setuid 2
+chmod u+s /usr/bin/mtr
+fi
+fi
+
+#DEBHELPER#
+
+exit 0
diff --git a/debian/rules b/debian/rules
index 05ce1e8..d416d7c 100755
--- a/debian/rules
+++ b/debian/rules
@@ -64,6 +64,7 @@ binary-arch: build
# Add here commands to install the files into debian/tmp
$(MAKE) -C mtr-tiny prefix=`pwd`/debian/mtr-tiny/usr install
mv mtr-tiny/debian/tmp/usr/bin/mtr debian/mtr-tiny/usr/bin/
+ chmod 0755 debian/mtr/usr/bin/mtr-tiny
dh_installdocs -pmtr-tiny
# dh_installexamples -mtr-ptiny
@@ -87,6 +88,7 @@ binary-arch: build
dh_installdirs -pmtr
$(MAKE) -C mtr prefix=`pwd`/debian/mtr/usr install
mv mtr/debian/tmp/usr/bin/mtr debian/mtr/usr/bin/
+ chmod 0755 debian/mtr/usr/bin/mtr
dh_installdocs -pmtr
# dh_installexamples -pmtr
Bug#564874: manpages: Please ship ld.so manpage
On Mon, Jul 22, 2013 at 08:28:43PM +0200, Michael Kerrisk (man-pages) wrote: Yup, I already noticed that older LD_ASSUME_KERNEL values gave results such as the above. However, I was not sure of the intention of your response? Did you mean that the proposed text should be changed? If so, could you be more specific about what changes you'd like. I'm not sure there's any point in documenting the use of the 2.2.5 version to disable TLS, when that's just obsolete now. The rest seemed fine. (I don't think glibc currently has any interesting values for LD_ASSUME_KERNEL - until the next ABI change it's probably useless) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564874: manpages: Please ship ld.so manpage
Things from my past coming back to haunt me, but if people want to keep ccing me... On Sat, Jul 20, 2013 at 10:15:25PM +0200, Michael Kerrisk wrote: Yes. I've never been quite sure though whether the particular kernel versions to specify for LD_ASSUME_KERNEL when selecting the threading implementation are distro-specific, so I'm reluctant to go into the detail in the page. As you note, I do hint at the 2.2.5 version in the pthreads(7): asuffield@cyclone:~$ readelf -n /lib/x86_64-linux-gnu/libc.so.6 Notes at offset 0x0270 with length 0x0024: Owner Data size Description GNU 0x0014 NT_GNU_BUILD_ID (unique build ID bitstring) Build ID: cddff8f45f5aa7b5ce64717e9e6ae3899f27972c Notes at offset 0x0294 with length 0x0020: Owner Data size Description GNU 0x0010 NT_GNU_ABI_TAG (ABI version tag) OS: Linux, ABI: 2.6.26 asuffield@cyclone:~$ LD_ASSUME_KERNEL=2.6.25 /bin/true /bin/true: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory asuffield@cyclone:~$ LD_ASSUME_KERNEL=2.6.26 /bin/true asuffield@cyclone:~$ Apparently glibc has moved on and there's nothing in wheezy that can use the old numbers. I expect other distros are similar. This information is probably only of historical interest now. The number 2.2.5 used to be special because it was the *minimum* version supported by the non-TLS libc that was shipped at the time. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#645309: debpartial-mirror: cannot handle duplicate entries in Packages
Package: debpartial-mirror Version: 0.2.99 Severity: grave (Normally important, but bumped to RC because it's breaking for security updates on squeeze and that needs to not happen) If a Packages file contains two entries for the same package name, debpartial-mirror will die with this exception: Traceback (most recent call last): File /usr/bin/debpartial-mirror, line 177, in module main() File /usr/bin/debpartial-mirror, line 169, in main controller.executeCommand(cmnd) File /usr/lib/pymodules/python2.6/debpartial_mirror/Controller.py, line 34, in executeCommand self._commands.get(commandName)() File /usr/lib/pymodules/python2.6/debpartial_mirror/Controller.py, line 38, in doAll if self._load(): File /usr/lib/pymodules/python2.6/debpartial_mirror/Controller.py, line 72, in _load if not b.load(): File /usr/lib/pymodules/python2.6/debpartial_mirror/Backend.py, line 111, in load return self._dists.load() File /usr/lib/pymodules/python2.6/debpartial_mirror/Dists.py, line 186, in load processTagFile(index_filename, addPackage) File /usr/lib/pymodules/python2.6/debpartial_mirror/Dists.py, line 487, in processTagFile sectionHandler(section) File /usr/lib/pymodules/python2.6/debpartial_mirror/Dists.py, line 182, in addPackage pkglist.add(package) File /usr/lib/pymodules/python2.6/cdd/PackageList.py, line 167, in add raise PackageAlreadyExists, package['Package'] cdd.PackageList.PackageAlreadyExists Trivial patch follows which only mirrors the most recent version (which is probably what you wanted, and anyway much better than failing). diff -b -x debian -x DEBIAN -x build -ruN debpartial-mirror-0.2.99//debpartial_mirror/Dists.py /home/asuffield/src/debpartial-mirror-0.2.99//debpartial_mirror/Dists.py --- debpartial-mirror-0.2.99//debpartial_mirror/Dists.py2010-10-22 21:58:37.0 +0100 +++ /home/asuffield/src/debpartial-mirror-0.2.99//debpartial_mirror/Dists.py 2011-10-14 10:37:56.207266435 +0100 @@ -179,6 +179,14 @@ def addPackage(section): package = pkg(section) package.releaseInfo = releaseInfo +name = package['Package'] +if name in pkglist: +oldver = pkglist[name]['Version'] +newver = package['Version'] +if apt_pkg.version_compare(oldver, newver) 1: +pkglist.remove(name) +pkglist.add(package) +else: pkglist.add(package) index_filename = os.path.join(self._filesystem.base(), file) Right now, security.debian.org has duplicates on amd64 for these packages: Package: openjdk-6-doc Package: openjdk-6-jre-lib Package: openjdk-6-source Thijs Kinkhorst observed that this is because openjdk is hard to build on all architectures and they still don't have the latest update on powerpc and sparc, and suggested that this is just something that will happen from time to time. Also it's probably going to happen all the time for sid. I'm surprised this wasn't noticed and fixed before now. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639916: spread: license wackiness
Package: spread Severity: serious 3. All advertising materials (including web pages) mentioning features or use of this software, or software that uses this software, must display the following acknowledgment: This product uses software developed by Spread Concepts LLC for use in the Spread toolkit. For more information about Spread see http://www.spread.org; Seriously? For -legal: consider this page: http://packages.debian.org/squeeze/spread -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639916: spread: license wackiness
On Wed, Aug 31, 2011 at 07:28:03PM +0200, Francesco Poli wrote: On Wed, 31 Aug 2011 15:50:27 +0100 Andrew Suffield wrote: Package: spread Severity: serious 3. All advertising materials (including web pages) mentioning features or use of this software, or software that uses this software, must display the following acknowledgment: This product uses software developed by Spread Concepts LLC for use in the Spread toolkit. For more information about Spread see http://www.spread.org; For -legal: consider this page: http://packages.debian.org/squeeze/spread What should I consider, more precisely? Why does this webpage, which mentions features and use of the software, not contain the statement required by the license? Is this requirement one which Debian can realistically satisfy? How did this absurdity ever get in? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639713: debian-installer: grub-install fails during squeeze install if /boot is on raid and mdadm was not installed
Package: debian-installer It may require a preseed file to get this to happen. Regardless, something should have added mdadm to the list of packages to install if raid devices were used.
Bug#628150: partman-auto: Conspires to commit inappropriate error reporting when expert recipe fails to parse
Package: partman-auto
When there is a parse error in the start of a line in an expert recipe, it
responds as follows:
The minimum partition size is set to 22, with a comment in the
source remarking there is no so big storage device jet.
Since the recipe does not fit on the disk, it files this message in syslog:
Available disk space ($free_size) too small for expert recipe
($(min_size)); skipping
And then it proceeds to use the default recipe. Since I'm using this in a
fully preseeded install, it does this silently and without any indication
that an error has occurred. I simply get a system installed with a
(hilariously inappropriate, would not boot at all) partition layout.
Here's an example of a suitably broken recipe:
d-i partman-auto/expert_recipe string \
xenhost :: \
25000 5 25000 ext3 \
$primary{ } method{ format } format{ } use_filesystem{ } filesystem{
ext3 } mountpoint{ / } \
. \
100 1000 10 ext3 \
$defaultignore{ } \
$primary{ } \
method{ lvm } \
device{ /dev/sda } \
vg_name{ vg1 } . \
. \
100 1000 10 ext3 \
$defaultignore{ } \
$primary{ } \
method{ lvm } \
device{ /dev/sdb } \
vg_name{ vg2 } . \
. \
100 1000 10 ext3 \
$defaultignore{ } \
$primary{ } \
method{ lvm } \
device{ /dev/sdc } \
vg_name{ vg3 } . \
. \
100 1000 10 ext3 \
$defaultignore{ } \
$primary{ } \
method{ lvm } \
device{ /dev/sdd } \
vg_name{ vg4 } . \
.
(Note the spurious extra . at the end of each block)
This error non-reporting needs to be stopped. The install should be
interrupted with an actual error, not continue with an entirely different
layout and quietly mention it in syslog.
Bug#467563: camlp5 strict vs transitional
The request is still applicable; the suggested solution is poor. A given piece of software may wish to use both strict and transitional versions on different components. A better solution is to build it both ways and supply /usr/bin/camlp5 for transitional, and /usr/bin/camlp5-strict for strict (you can split the package three ways to camlp5-strict, camlp5-transitional, and camlp5-doc). Use ./configure --strict --name=camlp5-strict and it should rename everything appropriately. It's a bit of a mess. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578171: mysql-server-5.1: install fails when password contains quote
Package: mysql-server-5.1 On a fresh install, using a password with a in it causes this failure: ERROR: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') WHERE user='root'' at line 1 Obviously a lack of escaping somewhere. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570165: avahi-daemon hangs
I just observed this behaviour on one server. No relevant debug output, no obvious trigger, but at random intervals avahi causes all network services to lock up. Uninstalling avahi makes the problem go away. I can't take that box down to debug it further. It should never have been installed in the first place; unclear quite how something as obscure as zeroconf managed to find its way onto a box that only does DNS, DHCP, mail, and samba. Perhaps a stray Recommends somewhere? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564874: manpages: Please ship ld.so manpage
Package: manpages Version: 3.23-1 Severity: normal The current ld.so manpage is from glibc. It's gratuitously out of date and just plain wrong in places. The one in manpages is current and reasonably accurate. Please arrange for the version from manpages to be shipped instead of the glibc version. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563714: xemacs21: crash (assertion failed) when calling function from haskell-mode
Package: xemacs21 Version: 21.4.22-2 Severity: important asuffi...@cyclone:~$ xemacs -vanilla -batch -eval (haskell-mode) -eval (turn-on-haskell-ghci) haskell-ghci is obsolete. Loading haskell-ghci...Fatal error: assertion failed, file bytecode.c, line 1479, ABORT() Aborted (core dumped) Obviously it should not be crashing. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30.5.cyclone (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xemacs21 depends on: ii xemacs21-mule 21.4.22-2 highly customizable text editor -- xemacs21 recommends no packages. xemacs21 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#538757: panic:restartop and segfault in perl interpreter
Package: perl Version: 5.10.0-24 asuffi...@cyclone:~/work/perl-bug$ cat One.pm package One; use Moose; use overload '' = 'stringify'; use Two; asuffi...@cyclone:~/work/perl-bug$ cat Two.pm package Two; One-new(); asuffi...@cyclone:~/work/perl-bug$ perl -MOne panic: restartop Segmentation fault (core dumped) asuffi...@cyclone:~/work/perl-bug$ perl --version This is perl, v5.10.0 built for x86_64-linux-gnu-thread-multi Inspection with valgrind indicates that the segfault is a read-after-free error, which suggests bad reference counting somewhere - but that comes *after* the panic, so it may simply be a double fault. Alas, my perl-fu is too rusty to track down problems this deep in the interpreter, it's changed a lot since I last looked in there. Of course, there's no guarantee that this is an actual perl bug. It could be one of the data structures getting mangled by any of these: 0x7f66c75547d0 0x7f66c7559088 Yes /usr/lib/perl/5.10/auto/List/Util/Util.so 0x7f66c735 0x7f66c7350bd8 Yes /usr/lib/perl5/auto/Sub/Name/Name.so 0x7f66c714dd70 0x7f66c714e508 Yes /usr/lib/perl5/auto/Devel/GlobalDestruction/GlobalDestruction.so 0x7f66c6f497d0 0x7f66c6f4c248 Yes /usr/lib/perl5/auto/Params/Util/Util.so 0x7f66c6d43250 0x7f66c6d46e28 Yes /usr/lib/perl5/auto/Class/MOP/MOP.so 0x7f66c6b2ee20 0x7f66c6b3fac8 Yes /usr/lib/perl5/auto/List/MoreUtils/MoreUtils.so Unfortunately there's no good way to determine which (or if it is in fact a perl bug) without heavy-duty triage. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#476692: [Linux-ha-dev] Re: Bug#476692: heartbeat: OCF Filesystem agent doesn't check /proc/mounts
On Mon, Apr 21, 2008 at 10:22:01AM +0100, David Lee wrote: Solaris doesn't have a /proc/mounts. What it does have is the ability (like Linux) to list the kernel mount table from a simple mount command. Irritatingly, the Linux 'mount' command doesn't do this, it merely dumps out whatever is in /etc/mtab at the time. This is because some information relating to loopback and user mounts is only available in mtab, since it's only used by the userspace tools. This means it is similarly unreliable - the only way to find out what the kernel's really up to on Linux is to inspect /proc/mounts directly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476692: heartbeat: OCF Filesystem agent doesn't check /proc/mounts
Package: heartbeat
The OCF Filesystem agent uses this code to monitor the mounted
filesystems:
list_mounts() {
if [ -f /etc/mtab -a -r /etc/mtab ]; then
cut -d' ' -f1,2,3 /etc/mtab
else
$MOUNT | cut -d' ' -f1,3,5
fi
}
Since what we're interested in is servers which are failing, there's a
chance that mtab will be out of date compared to the kernel status. It
should be checking /proc/mounts when that's available.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476700: heartbeat: failed html to text conversions
Package: heartbeat [EMAIL PROTECTED]:~$ cat /usr/share/doc/heartbeat/GettingStarted.txt Lynx or w3m or user-defined HTML2TXT required to convert GettingStarted.html to GettingStarted.txt Presumably a build error. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425694: kaya: uninstallable (dependency on g++-4.0)
Package: kaya Severity: serious The following packages have unmet dependencies. kaya: Depends: g++-4.0 but it is not installable -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406704: iceweasel: about dialog has bogus 'license' text
On Mon, Jan 15, 2007 at 07:57:00PM -0500, Eric Dorland wrote: I'm getting some pushback from upstream on this actually and on second thought I'm leery to fuddle with someones copyright assertion, as innocuous as it may be. I'm going to wait for upstream to make a call. I find it deeply amusing that a supposedly free software project cites a list of proprietary software examples (for which all rights *are* reserved) when trying to justify what their license text says. I find it even more amusing that they're willing to expend pages and pages of discourse for what is little more than a documentation inconsistency that could be fixed by copying a couple of lines from the about: text to the dialog text. In fact, I cannot imagine any compelling reason why these two things should not be identical - it's not like the about: text wouldn't fit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406704: iceweasel: about dialog has bogus 'license' text
On Sun, Jan 14, 2007 at 04:50:23PM -0500, Eric Dorland wrote: * Andrew Suffield ([EMAIL PROTECTED]) wrote: Package: iceweasel The dialog displayed when selecting the Help - About menu says 'All rights reserved'. That's just wrong. I suppose it wrong. I wonder why they have it there. I expect it's a relic from 1994, when Netscape was proprietary, and nobody ever bothered to update it when they were fixing the about: text. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406704: iceweasel: about dialog has bogus 'license' text
Package: iceweasel The dialog displayed when selecting the Help - About menu says 'All rights reserved'. That's just wrong. The page accessed via the about: URL has a link to about:license, which has the correct information. The dialog should say something similar. Also, the weasel looks like it wants to bite something. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404465: /usr/games/dab: fails to reset terminal on exit
Package: bsdgames Run dab. Hit q. Your terminal is now -inlcr -ocrnl -icanon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387515: cg-commit -p -m ignores -p
Package: cogito cg-commit -p -m ignores the -p argument and silently commits. Yes, this is documented, but it's still stupid behaviour; if the user had meant that, they would have just used -m alone. At the very least, it should abort with an error (on the basis that the command makes no sense); more sensibly, it should create a log message with the given string and then spawn an editor (and then since the user will probably exit without changing the file, the Abort or commit? message would appear as per usual, which seems to me to be appropriate behaviour). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#231399: filelight: memory usage is obscene
On Wed, Aug 30, 2006 at 12:50:10AM +0200, Tomas Pospisek wrote: Running filelight over my 100Gb home directory (600k inodes, ~10 million files) resulted in it allocating 400Mb of memory, of which 200Mb was actually used. Could you double check this? To me it looks like filelight is doing better these days. Scanning my 20G partition with 500k files: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 17044 tpo 16 0 70176 48m 13m S 0.0 6.4 0:35.73 filelight I now have 800k files and a roughly equal number of inodes (no huge hardlink forest these days), using 90Mb/70Mb, which is more reasonable (still more than xdiskusage, but probably attributable to Qt waste rather than a bug). Unless it had something to do with the hardlinks, I expect this changelog entry is the relevant one: 1.0-beta3 Found big memory leak thanks to valgrind! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#352429: O: cdrdao -- records CDs in Disk-At-Once (DAO) mode
Package: wnpp Severity: normal I'm orphaning cdrdao, since I actually don't need it any more (a combination of bchunk, xine, daemon-tools, and effective dvd burning on my desktop means that I no longer need to actually put this stuff on CDs) and it's a real bitch to look after. Buyer beware, this package is fundamentally unstable because it's taking a library written by a lunatic and trying to wrap a new interface around it. You're probably better off finding another way to solve your problem instead of trying to maintain this thing. The package description is: cdrdao records audio or data CD-Rs in disk-at-once (DAO) mode based on a textual description of the CD contents. . Recording in disk-at-once mode writes the complete disc, i.e. lead-in, one or more tracks and lead-out, in a single step. The commonly used track-at-once (TAO) mode writes each track independently which requires link blocks between two tracks. You probably want to use this if you're copying a CD with multiple tracks, like most audio CDs. . cdrdao can also handle the bin/cue format commonly used for VCDs or disks with subchannel data. . If you just want to burn a normal data CD, you probably want cdrecord instead. signature.asc Description: Digital signature
Bug#352430: O: fspanel -- minimalist panel for X
Package: wnpp Severity: normal I'm orphaning fspanel. This package is so simple that it should keep working for years; if X hadn't bitrotted under it then it would be releasing the same version in etch as in sarge. It probably doesn't need a maintainer, so it may as well stay in the archive even if nobody picks it up. The package description is: A panel for X that lists all your windows, while consuming minimal disk, memory, and screen space. It works under any gnome compliant window manager (eg. E, Sawfish, WindowMaker, IceWM, Oroborus) and supports KDE's mini icons (the KWM_WIN_ICON atom). signature.asc Description: Digital signature
Bug#352431: O: icheck -- C interface ABI/API checker
Package: wnpp Severity: normal I'm orphaning icheck. As far as I'm aware it doesn't have much of a userbase since the original plans for its deployment in Debian never happened, and I'm the upstream author, so it's probably dead now. Also the chances of anybody else understanding the thing are pretty slim. It should probably be removed. The package description is: A tool for statically checking C interfaces for API and ABI changes. All changes to type declarations that can cause ABI changes should be detected, along with most API changes. . icheck is intended for use with libraries, as a method of preventing ABI drift. signature.asc Description: Digital signature
Bug#351582: O: tla -- arch revision control system
Package: wnpp Severity: normal I'm orphaning tla; I don't really use the thing any more. The package description is: arch is a revision control system with features that are ideal for projects characterised by widely distributed development, concurrent support of multiple releases, and substantial amounts of development on branches. It can be a replacement for CVS and corrects many mis-features of that system. . tla is an implementation of arch in C, by Tom Lord. signature.asc Description: Digital signature
Bug#351583: O: arch-buildpackage -- tools for maintaining Debian packages using arch
Package: wnpp Severity: normal I'm orphaning arch-buildpackage, since I don't really use arch now. The package description is: arch-buildpackage is a set of tools to simplify maintaining Debian packages with arch. It is oriented around configurations, in order to avoid placing restrictions on the layout of branches used. signature.asc Description: Digital signature
Bug#347241: cdrdao: cue2toc and its manpage are still in the package
On Thu, Jan 19, 2006 at 08:26:46AM -0500, Edward J. Shornock wrote: cue2toc still exists in the upgraded package: Argh, fiddling with the damn diff and lost the damn change before uploading, I'll take care of it tomorrow. -- Andrew Suffield signature.asc Description: Digital signature
Bug#348746: O: dancer-ircd
Package: wnpp Severity: normal I don't use this any more. It's not maintained upstream and not likely to be, but it doesn't really need much maintaining upstream. -- Andrew Suffield signature.asc Description: Digital signature
Bug#348748: O: dancer-services
Package: wnpp Severity: normal I don't use this any more. It's also fragile and hasn't been properly maintained upstream in years. If nobody wants it, it should be removed. -- Andrew Suffield signature.asc Description: Digital signature
Bug#346684: intent to upload sponsored NMU to fix xlibs-dev bug
On Mon, Jan 16, 2006 at 01:41:50AM -0500, Justin Pryzby wrote: tag 346684 patch thanks I intend to NMU a fix for this bug sponsored by some member of the QA group; patch attached. Do you people even read the bug logs? That's two of you in less than 24 hours. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=346684;msg=20 -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#348154: lvm2: fails to upgrade (and probably install)
Package: lvm2 Severity: serious Version: 2.02.01-2 From preinst: #! /bin/sh set -e [...] if [ `/sbin/lvmiopversion` -le 10 ]; then [ -x /sbin/lvscan ] /sbin/lvscan 2/dev/null | grep Snapshot 21 /dev/null if [ $? = 0 ]; then You cannot do this in set -e. The script will always abort and fail if $? is not zero. You'll have to set +e or put the if around the command. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#346684: Intend to NMU fspanel
On Sun, Jan 15, 2006 at 06:05:58PM +0100, Nico Golde wrote: I intend to NMU fspanel package, are you already working on the bug? It's on my todo list for the next few days. This bug is less than a week old. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#346362: azureus: disable annoyware
Package: azureus
Turns out that azureus is annoyware, wasn't expecting that. If you
select Help - Make a donation then the window it throws up cannot
be closed until it's done playing a silly animation. Here's a patch to
turn that pesky behaviour off so that you can close it immediately.
Also it opens this window at intervals on its own. Attaching another
patch to disable that too. There's no way I could deploy something
like that to users.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -- |
--- azureus-2.3.0.6/org/gudy/azureus2/ui/swt/donations/DonationWindow2.java~
2005-11-21 20:42:34.0 +
+++ azureus-2.3.0.6/org/gudy/azureus2/ui/swt/donations/DonationWindow2.java
2006-01-07 10:50:49.0 +
@@ -280,7 +280,7 @@
//Of other controls (Not sure about this, but should be right)
//Gudy :p
ok = new Button(shell,SWT.PUSH);
- ok.setEnabled(false);
+ ok.setEnabled(true);
Messages.setLanguageText(ok,DonationWindow.ok);
formData = new FormData();
--- azureus-2.3.0.6/org/gudy/azureus2/ui/swt/donations/DonationWindow2.java
2005-11-21 20:42:34.0 +
+++ azureus-unannoy/org/gudy/azureus2/ui/swt/donations/DonationWindow2.java
2006-01-07 11:32:57.0 +
@@ -280,7 +280,7 @@
//Of other controls (Not sure about this, but should be right)
//Gudy :p
ok = new Button(shell,SWT.PUSH);
- ok.setEnabled(false);
+ ok.setEnabled(true);
Messages.setLanguageText(ok,DonationWindow.ok);
formData = new FormData();
@@ -412,5 +412,9 @@
}
public static void checkForDonationPopup() {
+return;
+ }
+
+ public static void checkForDonationPopup_disabled() {
try{
class_mon.enter();
signature.asc
Description: Digital signature
Bug#346381: glurp: misplaced glurp.svg
Package: glurp [EMAIL PROTECTED]:~$ /usr/bin/glurp (glurp:32134): libglade-WARNING **: Error loading image: Failed to open file '/usr/share/glurp/glurp.svg': No such file or directory Which is because it's over here: -rw-r--r-- 1 root root 2674 2005-10-04 12:22 /usr/share/pixmaps/glurp.svg Not that it seems to affect anything. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#346394: samba-dbg: no symbols for anything but samba
Package: samba-dbg There's no debugging symbols for anything from the winbind, libsmbclient, and smbclient packages (at least) - in fact, nothing except the contents of the samba package itself. I don't think you meant to do that. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#346409: gdb: fails to function at all on stuff linked with -pie
Package: gdb
Our gdb doesn't work on PIE binaries. I don't know why you'd ever want
to do this, but right now samba is linked that way. I'm just going to
file a bug over there asking them to stop, but this should probably be
fixed anyway. Supposedly fedora's gdb works; I haven't tried it.
Sample:
[EMAIL PROTECTED]:~$ cat hello.c
#include stdio.h
#include unistd.h
int main(void)
{
printf(Hello, fuckers!\n);
sleep(1000);
return 0;
}
[EMAIL PROTECTED]:~$ gcc -pie -o hello hello.c
[EMAIL PROTECTED]:~$ gdb hello
GNU gdb 6.4-debian
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i486-linux-gnu...Using host libthread_db library
/lib/tls/i686/cmov/libthread_db.so.1.
(gdb) b main
Breakpoint 1 at 0x612
(gdb) r
Starting program: /home/asuffield/hello
Warning:
Cannot insert breakpoint 1.
Error accessing memory address 0x612: Input/output error.
I couldn't find anything that actually worked, gdb does not appear to
understand these binaries at all. Most notably, it cannot attach to
their processes and produce a stack trace, which is proving to be
quite problematic for debugging samba.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -- |
signature.asc
Description: Digital signature
Bug#346416: samba: panic actions script is useless because samba is built with -pie
Package: samba Version: 3.0.20b-1 You may have noticed that recently, all or most of your bug reports from /usr/share/samba/panic-action have had stack traces filled with ??s instead of useful information. They'll all take this form: #0 0xe410 in __kernel_vsyscall () #1 0xb7f293f0 in ?? () #2 0xb7f29213 in ?? () #3 0xbf8f7124 in ?? () #4 0xbf8f7124 in ?? () #5 0x in ?? () That's because all of samba's binaries are being linked with -pie, which is breaking gdb (I just filed #346409 there about it). For now you can make the problem go away by passing --disable-pie to configure. This misfeature was added upstream in samba 3.0.20. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#346230: gsm-utils: uselessly installs non-executable scripts into /usr/bin
Package: gsm-utils Severity: important /usr/bin/gsmsmsspool and /usr/bin/gsmsmsrequeue are not executable -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#346238: gsm-utils: deletes and recreates the gsmsms user on each upgrade (!?)
Package: gsm-utils Severity: important gsm-utils calls deluser unconditionally on gsmsms in prerm, so that the user is removed and recreated on every upgrade. Don't do that, it's crazy. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#346240: gsm-utils: syslog support does not work
Package: gsm-utils Despite being invoked with the -L option, gsmsmsd doesn't log anything to syslog. A quick glance at the source indicates that this is because it doesn't actually process the -L option at all - adding the relevant case 'L': enableSyslog = true; break; makes it work. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#257162: Mail::Message::Head::Complete::guessTimestamp complains for mails with no 'date' or 'received' headers
On Thu, Dec 29, 2005 at 11:36:57PM +0200, Niko Tyni wrote: However, when this report was finally forwarded upstream (https://rt.cpan.org/NoAuth/Bug.html?id=15900), the upstream author replied: If a message is created using the provided MailBox methods, like build(), it willo have a Date field. If it is an incoming message, the mail-delivery agent will add received lines. So: the question is: why aren't we in either case? Is a different line added? The only good fix is to produce a time-stamp based on some other fact. Which fact? Could you comment on this? How did you end up with a message with neither Date: nor Received: fields? Good question. Unfortunately, answering it would require that I remember what project I was working on at a point some 18 months ago... I don't have the faintest idea. Obviously it happened somehow. My *guess* would be that it was acquired via Mail::Message-read and the mail I read in did indeed have neither field. There's a good chance that I was doing something with a mail that happened to be 'not strictly valid', but that's depressingly common with mail. If it had no Received line then it was probably supplied by the user. On reflection it would not be unreasonable to croak in this case (although I'd hope that something more permissive would work, like using the current time), and I was probably objecting to it 'working' but spewing an incomprehensible warning - it should either work cleanly or throw an exception. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#344018: libuniversal-exports-perl: contains UNIVERSAL::require, which breaks on sarge dpkg
Severity: important Package: libuniversal-exports-perl libuniversal-exports-perl still contains UNIVERSAL::require, and relies on libuniversal-require-perl's Replaces relation to shift the files where they belong. Unfortunately this doesn't work with the version of dpkg in sarge, so it's going to fail upgrades. You could fiddle around with Conflicts/Depends or something... but the simplest solution is to stop shipping the old files in libuniversal-exports-perl. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#343582: update-notifier: WTF is this?
Package: update-notifier The package description says this: update-notifier - Daemon which notifies about package updates Puts an icon in the user's notification area when package updates are available. It what? What notification area? What package updates? This description doesn't tell me anything particularly useful about the package; in fact, I think my understanding has been slightly reduced after reading it. When you rewrite it, use more than one sentence. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#343606: libcatalyst-perl: missing build-dep on libtemplate-perl
Package: libcatalyst-perl Severity: serious Version: 5.61-1 Fails to build without Template available, it's in Makefile.PL... -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#343107: debians perl requires an extreme amount of stack
On Mon, Dec 12, 2005 at 09:05:38PM +0100, Marc Lehmann wrote:
This is the beginning of Perl_magic_get in debians (debug)perl on the same
system:
0x004aaf61 Perl_magic_get+0: push %rbp
0x004aaf62 Perl_magic_get+1: mov%rsp,%rbp
0x004aaf65 Perl_magic_get+4: push %r12
0x004aaf67 Perl_magic_get+6: push %rbx
0x004aaf68 Perl_magic_get+7: sub$0x40150,%rsp
This allocates 262480 bytes(!) (in words: a quarter megabyte) of local
variables on the stack.
#ifdef HAS_GETGROUPS
{
Groups_t gary[NGROUPS];
i = getgroups(NGROUPS,gary);
while (--i = 0)
Perl_sv_catpvf(aTHX_ sv, %Gid_t_f, gary[i]);
}
#endif
sizeof(gid_t) (4) * NGROUPS (65536) == 256kb
Idiotic way to write that code. It should be fetching the number of
groups with getgroups(0, NULL) and then allocating dynamically. This
happens in several places.
I don't know why your copy didn't build support for large
supplementary group lists.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -- |
signature.asc
Description: Digital signature
Bug#335105: perl FTBFS in t/op/fork
On Sat, Dec 10, 2005 at 07:39:04PM +0100, Thiemo Seufer wrote: Andrew Suffield wrote: This doesn't look like #223110 to me - that bug is specific to signal handlers. After a closer look I agree. I just tried the test on casals against 5.8.7-6 though, and I can't get it to break (although it is still breaking on the buildd). What do you know about it? I need to duplicate the pesky thing somehow... Hm, it is easily reproducible on SWARM, as well as on a Octane with 2 CPUs. Which probably means it is a SMP-induced race condition in fork. My bet is that it's this kernel bug: I don't know if you've been following, but it was recently discoverd that on smp, if multiple processes read from /dev/urandom at the same time, they can get the same data. Theodore Tytso posted a patch to fix this for 2.6, and someone else told me this problem has existed all the way back to 1.3. Fixed in 2.4.29 and 2.6.5. What kernel version have you got there? If it's 2.4.27 (sarge) then I think we have our problem found. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#335105: perl FTBFS in t/op/fork
This doesn't look like #223110 to me - that bug is specific to signal handlers. I just tried the test on casals against 5.8.7-6 though, and I can't get it to break (although it is still breaking on the buildd). What do you know about it? I need to duplicate the pesky thing somehow... -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#342468: tla package build failure in make test for undo test
severity 342468 normal thanks On Wed, Dec 07, 2005 at 08:21:13PM +0100, Christoph Scheurer wrote: Package: tla Version: 1.3.3-3 Severity: serious Justification: no longer builds from source Since the current development archive of tla can only be accessed with tla version = 1.3.2 I tried to backport 1.3.3-2 to sarge. The build went fine but the tests failed with an apparent tar error: Failing to build on sarge is not RC. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#341169: apt-file: get out of /var/cache/apt
Package: apt-file Severity: important Don't trample upon the namespace of other packages. You can read from /var/*/apt. You can't write there. Put your files in /var/cache/apt-file/ where they belong. This isn't a policy violation but it should be. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#263887: cdrdao override disparity
reassign 263887 ftp.debian.org thanks Please change cdrdao's priority from extra to optional. k3b wants to depend on it (see bug) and it's not really very extra. On Thu, Nov 24, 2005 at 04:17:08PM -0800, Debian Installer wrote: There are disparities between your recently accepted upload and the override file for the following file(s): cdrdao_1.2.1-1_i386.deb: package says priority is optional, override says extra. Either the package or the override file is incorrect. If you think the override is correct and the package wrong please fix the package so that this disparity is fixed in the next upload. If you feel the override is incorrect then please reply to this mail and explain why. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#295451: Please try with spamassassin 3.1.0a-1
On Wed, Nov 09, 2005 at 04:26:44PM -0500, Duncan Findlay wrote:
Does SpamAssassin 3.1.0 fix your problem?
Mail::SpamAssassin::BayesStore::DBM:
# use O_EXCL to avoid races (bonus paranoia, since we should be locked
# anyway)
my %new_toks;
$umask = umask 0;
$res = tie %new_toks, $self-DBM_MODULE, ${name}.new,
O_RDWR|O_CREAT|O_EXCL,
(oct($main-{conf}-{bayes_file_mode}) 0666);
Still got O_EXCL in there, so I presume it doesn't. Can't somebody
delete that already?
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -- |
signature.asc
Description: Digital signature
Bug#249634: cdrdao: simple fix for multiple FTBFS in scsilib
On Fri, Oct 28, 2005 at 11:31:53AM +0200, Kaare Hviid wrote: This is a small fix for handling a number of FTBFS problems in scsilib. And you could 'fix' most of the FTBFS bugs against perl by stopping it from running the testsuite, but I don't think either of these things is a very good idea. scsilib rarely works on new arches without being updated. No. The requirements for arches to be supported by cdrdao are the same as always: get the thing on ftp-master and thusly into Debian where I can see it. Otherwise it's just impractical. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#309735: Debianization patch against upstream 1.2.0
No way am I taking that patch, it's full of bugs claiming to be features in a huge tangled diff. A good example of why randomly applying patches does not make software better. Hint: if the bug you're looking at is tagged 'wontfix' and includes an explanation why, then 'fixing' it just shows that you can't read. For the record, I'm sitting on this one until the next upstream release, due shortly, because there are issues with rebuilding cdrdao right now and I really can't see any point in backporting the fixes just to get it in sid sooner. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#324135: arch-buildpackage: Does not exclude {arch} or .arch-id dirs when building
On Fri, Nov 04, 2005 at 06:32:27PM +0800, Zak B. Elep wrote: As shown, the `tar' to make the .orig.tar.gz is hard-coded. Hence, even Mr. Sogo's setting at ~/.archdeb.conf will not work, unless I copy the upstream .tar.gz manually to package/.*.orig.tar.gz. Which is exactly what you're supposed to be doing. Letting arch-buildpackage build one only makes sense when upstream uses arch, in which case you want to keep the control files. The whole point of this feature originally was to build tla itself directly from the upstream archive. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#324135: arch-buildpackage: Does not exclude {arch} or .arch-id dirs when building
On Fri, Nov 04, 2005 at 10:22:09PM +0800, Zak B. Elep wrote: On 11/4/05, Andrew Suffield [EMAIL PROTECTED] wrote: Which is exactly what you're supposed to be doing. Letting arch-buildpackage build one only makes sense when upstream uses arch, in which case you want to keep the control files. The whole point of this feature originally was to build tla itself directly from the upstream archive. I see. However, this assumes that the builder *has* a .tar.gz already at hand; Yes, it is assumed that the user is a Debian package maintainer, in which case they're going to be providing the upstream tarball. had that been not the case (or, instead of a .tar.gz, he has a .zip, or a .tar.bz2) the builder would soon see lintian errors about the generated .tar.gz having arch directories, Those are bogus warnings anyway. not to mention it being a native package when it not intended to be so. The file builds as a .orig.tar.gz, it won't build a tarball at all when running with --native - that's what dpkg-source is for. While I do see some convenience letting these arch dirs remain, I still feel that it would be equally convenient to be able to rebuild the source package from package/upstream, excluding the arch inventories and effectively rebuilding a clean source, as the builder can get that just as easily as the devo+debian tree. And you could carry on and say it's convinient to be able to build with arbitrary mangling of the source tree, but this all seems quite outside the scope of arch-buildpackage. It's only for preparing uploads to Debian, and functionally equivalent things. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#259973: Debian bug #259973: template primary group seems to be an unknown parameter
Good heavens, what an old bug. On Sat, Oct 22, 2005 at 11:37:44AM +0200, Christian Perrier wrote: Andrew (Suffield...as A. Bartlett is also following the Debian BTS, I have to avoid confusion), From what I see in samba sources, template primary group is not a recognized parameter for smb.conf (source/param/loadparm.c doesn't list it). It doesn't appear anywhere in the sourceexcept in WHATSNEW.txt and in a few places in Samba3-ByExample and Samba3-HOWTO. I can see it in 3.0.14a-6. It's this line: source/nsswitch/winbindd_acct.c:group = lp_template_primary_group(); Plus the associated config parsing stuff. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#332468: ipcalc: overzealous input checking
Package: ipcalc [EMAIL PROTECTED]:~$ ipcalc 0.0.0.0/0 INVALID MASK1: 0 No it isn't. Address: 0.0.0.0 ... Netmask: 255.255.255.0 = 24 ... And that's not helpful. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#249642: cdrdao: FTBFS amd64: x86_64 not supported
On Wed, Sep 07, 2005 at 08:44:16AM +0100, Free Ekanayaka wrote: |--== Andrew Suffield writes: AS On Tue, Sep 06, 2005 at 11:38:57AM +0100, Free Ekanayaka wrote: I among the ones who really would like to see cdrdao on Debian amd64. Is there any reason that prevent fixing this bug? AS Lack of an amd64 archive, or any particularly good reason to bother AS uploading it just for that. Also lack of any practical way to test it, AS given the absence of a Debian amd64 platform to test it on. I have a amd64 laptop at hand, I can test it out or even give you an account if needed. Testing it means reading and burning a bunch of CDs. AS I'm AS disinclined to do it on vague promises of an amd64 platform in the AS future Well, maybe the promise is not that vague, as we already have a fully working non official port and amd64 are becoming quite popular (more popular than other officially supported archs, for that matter). And it's completely unknown how similar or different it will be if/when there's a proper Debian amd64 platform. AS for something as horribly fragile and potentially destructive AS as cdrdao; that's how we get software in releases that creates AS coasters. I think I'm missing something. AFAICS the suggested patch in #249642 only concerns a couple of symlinks; if the source code is untouched why just rebuilding it should create coasters? Because cdrdao is fragile and frankly quite broken. It's constructed by taking a chunk of code from cdrecord, which is dodgy at best and only really understood by the somewhat crazy cdrtools author, and slapping a different frontend onto it. I've seen it break from more things I can easily count; the most common are updates to libscg, updates to gcc, and the release of new CD burners into the market. This is not something you can just rebuild and hope it will work. I don't even know if the version of libscg in cdrdao at present has even been ported to amd64, so I'd have to start by updating it from a cdrtools release that I know has been. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#326986: amd64 dpkg-architecture gives no information
reassign 326986 libnss-ldap thanks It's pure NSS, perl's just making the glibc calls. It's also user error for configuring it that way, but there's actually no right way to configure libnss-ldap in this scenario, just a selection of wrong ones. Anyway, suitably volleyed. Somebody who likes libnss-ldap can field it. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#249642: cdrdao: FTBFS amd64: x86_64 not supported
On Tue, Sep 06, 2005 at 11:38:57AM +0100, Free Ekanayaka wrote: I among the ones who really would like to see cdrdao on Debian amd64. Is there any reason that prevent fixing this bug? Lack of an amd64 archive, or any particularly good reason to bother uploading it just for that. Also lack of any practical way to test it, given the absence of a Debian amd64 platform to test it on. I'm disinclined to do it on vague promises of an amd64 platform in the future for something as horribly fragile and potentially destructive as cdrdao; that's how we get software in releases that creates coasters. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#321669: enigma: Copyright violation for menu.s3m
On Sun, Aug 28, 2005 at 05:35:36PM -0700, Don Armstrong wrote: On Sun, 28 Aug 2005, Francesco Poli wrote: On Sun, 28 Aug 2005 20:34:02 +0200 Sven Luther wrote: Erich, applying the GPL to a documentation is ok, but don't you think you are pushing things a bit hard by applying it to a music file too ? I don't think so. Any work can be released under the GPL, IMHO. You can release it, but it may not be possible for anyone else to distribute it if you don't distribute the prefered form for modification (and anything else that is required for other people to distribute the work.) [Of course, there is an argument that the DFSG requires source anyway, but we'll leave that one aside for now.] Soundtracker (and anything similar) modules such as we're dealing with here, like midi files, are usually their own source. As distinct from mp3 or wav files, which usually aren't. For those who don't know, a module is in essence a midi file with embedded instrument samples. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#284426: Trivial, annoying warning at boot time
On Thu, Aug 11, 2005 at 02:44:12AM +0200, Javier Fern?ndez-Sanguino Pe?a wrote: On Wed, Aug 10, 2005 at 06:37:30PM +0200, Miquel van Smoorenburg wrote: Actually, perhaps sysvinit should be a project on alioth with more than one developer doing the work. Sysvinit and related packages are more than just packaging. Sure, but, in the meantime, are you open to me uploading the attached NMU? I was going to do this in the next few days, but you've got a diff already, so I'll leave it for you. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#321838: bash: please put 'stty echo' in PROMPT_COMMAND in /etc/skel/.bashrc
Package: bash Severity: wishlist Sometimes applications go nuts and leave the terminal with echo disabled, which is quite annoying. If you arrange for PROMPT_COMMAND to run 'stty echo' then this is cleared before the prompt returns (apparently tcsh and some other shells do this by default). This would be nice to include in the default /etc/skel/.bashrc. Adding a line like this (below the existing xterm PROMPT_COMMAND magic) should do the trick: PROMPT_COMMAND=stty echo; $PROMPT_COMMAND -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#320986: debbugs: would like bug numbers in Closes: # text linked to the bugs
On Tue, Aug 02, 2005 at 12:30:14PM -0500, Branden Robinson wrote: It would be nice if, using the same regex that katie (or whatever) uses for automatically sending -done messages, debbugs would identify a Closes: # expression in a changelog and hyperlink the bug number to the bug report page. It's dpkg-parsechangelog. And it's /closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/ig -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#223110: Race condition between fork() and exit() when using pthread_atfork() from a shared library
Still present in 2.3.5-2. I've managed to do what none of the maintainers could do in the past year and a half, and forwarded this upstream. Nice bit of maintaining, there. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#320893: samba: updating smb.conf
Package: samba-common Severity: wishlist Okay, the default smb.conf is getting quite dated. Here's the pile of stuff I always have to change which would make sense as defaults: - passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n . + passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n *passwd:\spassword\supdated\ssuccessfully* Not sure when this changed, but the old one doesn't work any more for me. + add machine script = /usr/sbin/adduser --disabled-password --force-badname --no-create-home --ingroup machines --gecos Machine --home /home/samba/machines --shell /bin/false %u + add user to group script = /usr/sbin/adduser %u %g + delete user from group script = /usr/sbin/deluser %u %g Those should be included, commented out. It would also be possible to provide samba add/delete user/group scripts, but I don't use them for anything. add machine script is the really important one here, that's necessary to get domain joins working. + hide special files = yes This makes life a little less confusing for windows lusers, and it doesn't bother smart windows lusers because they've already configured windows to show hidden files. + map acl inherit = yes + store dos attributes = yes These two require the filesystem to be mounted with the user_xattr option, but simply do nothing if it isn't set, so I can't see a good reason not to turn them on by default. They cause samba to (at last!) store the dos attributes correctly. This is necessary for storing winxp profiles on the samba server, as otherwise the 'hidden' and 'system' bits go astray and desktop.ini files stop working, which screws up the start menu. (There's an old hack for mapping them to the unix execute bits, but that just sucks; this is much better). + enable privileges = yes This one is seriously useful. It does nothing directly, but it allows the use of the 'net rpc rights' command. Let's assume that you've already used 'net groupmap' to associate a unix group to the domain admins group. Now we can properly empower that group as follows: net -U root rpc rights grant 'Domain Admins' SeMachineAccountPrivilege With this plus the 'add machine script' line above, any user who is a member of the domain admins group can get NT boxes to join the domain, instead of having to use the 'root' account. There's other useful rights; see chapter 14 of the howto collection. But that's the really important one for me. However, in a situation where you're a domain client and not a domain controller, you probably don't want this, as it grants all that stuff to the *real* domain admins. So it should be included, commented out. + time server = yes Always handy to sync windows clients; their NTP implementation is utter crap. + winbind nested groups = yes These are useful, and I can't think of a reason not to turn them on. + domain logons = yes + logon path = \\%N\%U\.profile + logon drive = Z: + logon script = logon.bat These are only for a PDC, but I always have to look them up. They should be included, commented out, next to 'domain master'. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#319776: ntp: adjust default config files so ntpdate is unnecessary
Package: ntp-server Severity: wishlist ntp upstream considers ntpdate to be more or less unmaintained and sucky; we shouldn't be shipping ntpd in a configuration that expects it. Please add the 'iburst' option to the default server lines in ntp.conf, and the -g argument to the command line. (iburst is always a good thing to have; it lets ntpd sync up faster on startup. I can't think of a good reason for not having -g. You can still run ntpdate if you want to - it's just unnecessary). -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#319142: apt: attempts to install corrupted packages
Package: apt Severity: important [EMAIL PROTECTED]:~$ apt-cache show xfonts-scalable Package: xfonts-scalable ... Version: 6.8.2.dfsg.1-3 ... MD5sum: 0e9e786a6220993510e2b9cfdbc65ee1 Preparing to replace xfonts-scalable 4.3.0.dfsg.1-14 (using .../xfonts-scalable_6.8.2.dfsg.1-3_all.deb) ... Unpacking replacement xfonts-scalable ... dpkg: error processing /var/cache/apt/archives/xfonts-scalable_6.8.2.dfsg.1-3_all.deb (--unpack): corrupted filesystem tarfile - corrupted package archive: Success dpkg-deb: subprocess paste killed by signal (Broken pipe) [EMAIL PROTECTED]:~$ md5sum /var/cache/apt/archives/xfonts-scalable_6.8.2.dfsg.1-3_all.deb a525d80fb0df950f4e9b0e3141c63d0c /var/cache/apt/archives/xfonts-scalable_6.8.2.dfsg.1-3_all.deb Not only is this broken and annoying, it indicates that the security checking code is completely non-functional. (There's nothing strange going on here. This is the tail end of a regular upgrade that left me with hundreds of packages properly installed and three dead ones) -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#284426: Trivial, annoying warning at boot time
On Thu, Jul 14, 2005 at 05:20:26PM +0200, Javier Fern?ndez-Sanguino Pe?a wrote: Andrew, can you please NMU initscripts and fix the obnoxious #284426 bug? (Note #281651 and #316431 are also duplicates, and I'm merging them) I'm pretty much planning on doing that if I don't hear anything from the maintainer before I get home from debconf (so, Monday). And, if you do so, please also fix #314351, which can be trivially fixed. There are also some other trivial fixes: #289562, #311741, #281782, #269894, and #268713. If you could fix those too some people will really appreciate it. None of these look either important or annoying enough to merit NMUing. I'd rather wait until the maintainer wakes up and says something. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#284426: Trivial, annoying warning at boot time
This bug is now over six months old, and has had a patch for ages. It's
also utterly trivial to fix, and bloody annoying. What's going on?
I can upload the damn thing myself if need be. I have the package ready,
since I just rebuilt it myself for my own boxes. The patch I used is
attached.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -- |
reverted:
--- sysvinit-2.86.ds1.old/debian/changelog 2005-07-11 15:47:11.0
+0100
+++ sysvinit-2.86.ds1/debian/changelog 2005-07-11 16:10:52.0 +0100
@@ -1,3 +1,11 @@
+sysvinit (2.86.ds1-1.1) unstable; urgency=low
+
+ * NMU
+ * Fix stupid find warning by ordering the arguments correctly in
+/etc/init.d/bootclean.sh (closes: #284426)
+
+ -- Andrew Suffield [EMAIL PROTECTED] Mon, 11 Jul 2005 15:49:55 +0100
+
sysvinit (2.86.ds1-1) unstable; urgency=low
* New upload with a clean .orig.tar.gz archive without the .o files.
reverted:
--- sysvinit-2.86.ds1.old/debian/initscripts/etc/init.d/bootclean.sh
2005-07-11 15:47:12.0 +0100
+++ sysvinit-2.86.ds1/debian/initscripts/etc/init.d/bootclean.sh
2005-07-11 16:10:34.0 +0100
@@ -53,14 +53,14 @@
! ( -path ./.clean -uid 0 )
! ( -path './...security*' -uid 0 )'
+ ( if cd /tmp [ `find . -maxdepth 0 -perm -002` = . ]
- ( if cd /tmp [ `find . -perm -002 -maxdepth 0` = . ]
then
# First remove all old files.
+ find . -depth -xdev $TEXPR $EXCEPT \
+ ! -type d -print0 | xargs -0r rm -f
- find . -xdev $TEXPR $EXCEPT \
- ! -type d -depth -print0 | xargs -0r rm -f
# And then all empty directories.
+ find . -depth -xdev $DEXPR $EXCEPT \
+ -type d -empty -exec rmdir \{\} \;
- find . -xdev $DEXPR $EXCEPT \
- -type d -depth -empty -exec rmdir \{\} \;
rm -f .X*-lock
fi
)
signature.asc
Description: Digital signature
Bug#310792: libgnupg-perl: add support for missing public keys during validation
Package: libgnupg-perl
Severity: wishlist
Tags: patch
gpg helpfully reports when signature validation fails because the
public key isn't here. libgnupg-perl rather less helpfully discards
this information. Here's a patch to propagate it.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -- |
--- /usr/share/perl5/GnuPG.pm 2005-03-08 19:58:42.0 +
+++ GnuPG.pm2005-05-26 02:36:43.0 +0100
@@ -614,9 +614,17 @@
$self-abort_gnupg( invalid signature from , $arg =~ /[^ ](.+)/, \n )
if ( $cmd =~ /BADSIG/);
-$self-abort_gnupg( error verifying signature from ,
- $arg =~ /([^ ])/, \n )
- if ( $cmd =~ /ERRSIG/);
+if ( $cmd =~ /ERRSIG/)
+ {
+my ($keyid, $key_algo, $digest_algo, $sig_class, $timestamp, $rc)
+ = split ' ', $arg;
+if ($rc == 9)
+ {
+($cmd, $arg) = $self-read_from_status();
+$self-abort_gnupg( no public key $keyid );
+ }
+$self-abort_gnupg( error verifying signature from $keyid )
+ }
$self-abort_gnupg ( protocol error: expected SIG_ID )
unless $cmd =~ /SIG_ID/;
signature.asc
Description: Digital signature
Bug#309735: cdrdao: upstream 1.2.0 fix suid issues
On Thu, May 19, 2005 at 09:40:49AM +0200, Kaare Hviid wrote: From the new upstream 1.2.0 ChangeLog: o SECURITY FIX: cdrdao now gives up its root privileges after setting up real-time scheduling, as well as before saving settings through the --save option. This fixes a potential local root exploit when cdrdao is installed with the +s chmod flag. Using --save now also forces an early exit after the settings are saved. Although cdrdao isn't installed setuid root on Debian, no doubt some people find that an easy option, why it would be very nice if this release made its way into Debian. It hardly matters, once sarge is released I'll be uploading a version of cdrdao that refuses to be setuid. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#249642: [Call For Help] cdrdao: Please support the amd64/sarge release
On Thu, May 12, 2005 at 06:01:14PM +0200, Andreas Jochens wrote: there have been several request from amd64 users which would like to use cdrdao. Please reconsider applying the simple patch which adds amd64 support to cdrdao. Barring RC bugs, there is no way that any new uploads of cdrdao are going into sarge now. It's quite fragile enough already without getting rebuilt everywhere. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#249642: [Call For Help] cdrdao: Please support the amd64/sarge release
On Thu, May 12, 2005 at 09:05:33PM +0200, Andreas Jochens wrote: On 05-May-12 19:53, Andrew Suffield wrote: On Thu, May 12, 2005 at 06:01:14PM +0200, Andreas Jochens wrote: there have been several request from amd64 users which would like to use cdrdao. Please reconsider applying the simple patch which adds amd64 support to cdrdao. Barring RC bugs, there is no way that any new uploads of cdrdao are going into sarge now. It's quite fragile enough already without getting rebuilt everywhere. I think that the release team would consider to approve a fixed version of cdrdao for sarge. At least, similar approval has been given for quite a few other packages with amd64 related fixes. Probably, but I won't. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#306078: icheck: not for sarge
Package: icheck Severity: serious This one's not targetted for sarge, thanks. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304138: moomps: WTF?
On Thu, Apr 14, 2005 at 11:52:23PM +0200, Lars Steinke wrote: Monitoring daemon for moodss which sends alert emails or executes scripts when predefined thresholds are crossed. Personally, I gain three bits of information here: * It's to be used in conjunction with moodss solely * It's a monitoring daemon * It sends emails or executes scripts depending on thresholds That could be just about anything. Please comment on what is missing from your point of view (for a concise description, that is). Any conception of what the thing actually does or why I might want it. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#304571: certtool: DN input braindamage
Package: gnutls-bin
Tags: patch
The DN input mechanism used by certtool when creating certificates is
braindamaged. Instead of asking for a fully-formed DN, it asks for a
handful of attributes, and enforces a particlar order on them. This is
useless when you wanted a certificate that has a given attribute more
than once, or in a more normal order (who the heck puts O before OU,
or C at the start?).
Not exactly complete, because I couldn't remember all the attribute
names offhand, but here's a quickly hacked up patch that does it
properly. Supports c, ou, o, and cn, which is enough for most things
and lets me create my cn=foo, ou=bar, ou=baz, o=quux certificates.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -- |
diff -u gnutls11-1.0.16/src/certtool.c gnutls11-1.0.16/src/certtool.c
--- gnutls11-1.0.16/src/certtool.c
+++ gnutls11-1.0.16/src/certtool.c
@@ -248,14 +248,17 @@
/* set the DN.
*/
- get_country_crt_set( crt);
- get_organization_crt_set(crt);
- get_unit_crt_set( crt);
- get_locality_crt_set( crt);
- get_state_crt_set( crt);
- get_cn_crt_set( crt);
- get_uid_crt_set( crt);
- get_oid_crt_set( crt);
+if (!get_dn_crt_set( crt))
+ {
+get_unit_crt_set( crt);
+get_country_crt_set( crt);
+get_organization_crt_set(crt);
+get_locality_crt_set( crt);
+get_state_crt_set( crt);
+get_cn_crt_set( crt);
+get_uid_crt_set( crt);
+get_oid_crt_set( crt);
+ }
if (!batch) fprintf(stderr, This field should not be used in
new certificates.\n);
--- gnutls11-1.0.16.orig/src/certtool-cfg.c
+++ gnutls11-1.0.16/src/certtool-cfg.c
@@ -29,11 +29,13 @@
#include cfg+.h
#include gnutls/x509.h
#include string.h
+#include ctype.h
extern int batch;
typedef struct _cfg_ctx
{
+char *dn;
char *organization;
char *unit;
char *locality;
@@ -84,6 +86,7 @@
/* Option set */
struct cfg_option options[] = {
+ {NULL, '\0', dn, CFG_STR, (void *) cfg.dn, 0},
{NULL, '\0', organization, CFG_STR, (void *)
cfg.organization, 0},
{NULL, '\0', unit, CFG_STR, (void *) cfg.unit, 0},
{NULL, '\0', locality, CFG_STR, (void *) cfg.locality, 0},
@@ -245,6 +248,119 @@
return read_str( Enter the URI of the CRL distribution point:
);
}
+int attrcmp(const char *attr1, const char *attr2, size_t attr2_len)
+{
+ size_t attr1_len = strlen(attr1);
+ if (attr1_len != attr2_len)
+return 0;
+ return strncasecmp(attr1, attr2, attr1_len) == 0;
+}
+
+void dn_attr_crt_set( gnutls_x509_crt crt, const char *attr, size_t attr_len,
const char *value, size_t value_len)
+{
+ const char *oid = NULL;
+ int ret;
+
+ if (attrcmp(cn, attr, attr_len))
+oid = GNUTLS_OID_X520_COMMON_NAME;
+ else if (attrcmp(o, attr, attr_len))
+oid = GNUTLS_OID_X520_ORGANIZATION_NAME;
+ else if (attrcmp(ou, attr, attr_len))
+oid = GNUTLS_OID_X520_ORGANIZATIONAL_UNIT_NAME;
+ else if (attrcmp(c, attr, attr_len))
+oid = GNUTLS_OID_X520_COUNTRY_NAME;
+
+ if (!oid)
+{
+ fprintf(stderr, dn_attr_crt_set: unknown attribute '%.*s'\n, attr_len,
attr);
+ exit(1);
+}
+
+ ret = gnutls_x509_crt_set_dn_by_oid(crt, oid, 0, value, value_len);
+ if (ret 0) {
+fprintf(stderr, dn_attr_crt_set: %s\n, gnutls_strerror(ret));
+exit(1);
+ }
+}
+
+void dn_crt_set( gnutls_x509_crt crt, const char *dn)
+{
+ const char *p = dn;
+
+ /* For each element */
+ while (*p *p != '\n')
+{
+ const char *attribute_name_start;
+ const char *attribute_name_end;
+ const char *attribute_value_start;
+ const char *attribute_value_end;
+ size_t attribute_name_len;
+ size_t attribute_value_len;
+
+ /* Skip leading whitespace */
+ while (isspace(*p))
+p++;
+
+ /* Attribute name */
+ attribute_name_start = p;
+ while (isalpha(*p))
+p++;
+ attribute_name_end = p;
+
+ /* Whitespace */
+ while (isspace(*p))
+p++;
+
+ /* Equals sign */
+ if (*p != '=')
+{
+ fprintf(stderr, dn_crt_set: syntax error\n);
+ exit(1);
+}
+ p++;
+
+ /* Whitespace */
+ while (isspace(*p))
+p++;
+
+ /* Attribute value */
+ attribute_value_start = p;
+ while (*p *p != ',' *p != '\n')
+p++;
+ attribute_value_end = p;
+ while (attribute_value_end attribute_value_start
isspace(attribute_value_end[-1]))
+attribute_value_end--;
+
+ /* Comma, or the end of the string */
+ if (*p
Bug#304573: racoon-tool: useless sequence of operations on 'start'
Package: racoon Severity: important Version: 1:0.5-5 'racoon start' starts racoon before it generates the racoon config file. That's pretty useless. It will only ever work by coincidence. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#304097: dhclient: brainless waiting after DHCPOFFER
Package: dhcp-client Tags: patch After receiving a DHCPOFFER message, dhclient sits and waits for two seconds to allow an arp check to be run (to find out if the given address has been used for something else recently). Except that this isn't implemented in the default configuration (and shouldn't be); the test logic is wrong. This turns out to be two equally dumb issues. Firstly, dhclient-script returns success when invoked for ARPSEND, which indicates that it wants to do an ARP check; it should have failed. --- dhcp-2.0pl5.orig/client/scripts/linux +++ dhcp-2.0pl5/client/scripts/linux @@ -90,7 +90,11 @@ exit_with_hooks 0 fi -if [ x$reason = xARPCHECK ] || [ x$reason = xARPSEND ]; then +if [ x$reason = xARPSEND ]; then + exit_with_hooks 1 +fi + +if [ x$reason = xARPCHECK ]; then exit_with_hooks 0 fi Secondly, dhclient does not understand the meaning of the value returned by wait(). It thinks that the bottom eight bits contain the status code, which is simply not true (it varies per platform; changed to use the POSIX macros). --- dhcp-2.0pl5.orig/client/dhclient.c +++ dhcp-2.0pl5/client/dhclient.c @@ -2125,7 +2125,12 @@ ip - client - envc = 0; dfree (envp, script_go); } - return wstatus 0xff; + +if (WIFEXITED(wstatus)) + return WEXITSTATUS(wstatus); + +/* Anything else is considered failure */ +return 1; } void client_envadd (struct client_state *client, With these patches applied, dhcp requests on boot run in nothing flat, rather than holding up the boot process for two seconds per interface. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#304138: moomps: WTF?
Package: moomps After reading the description I still have no idea what this thing is or does. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#231457: Let's remove limewire
On Tue, Mar 22, 2005 at 10:48:24AM +1100, Andrew Pollock wrote: retitle 231457 RM: limewire -- orphaned, RC security bugs, in contrib reassign 231457 ftp.debian.org thanks I think we should remove limewire because: It has unsatisfiable build-dependencies, making it difficult to make a QA upload It has been orphaned for 409 days It has a RC security bug It has no reverse-dependencies It was never in a stable release And it's grossly out of date WRT upstream to the point of having security holes. Kill it. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#300391: af_vfs.h: missing #include sys/types.h line
Package: libaudiofile-dev Severity: important /usr/include/af_vfs.h uses ssize_t, but doesn't include sys/types.h, so it will fail to compile if nothing has included that first. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#299247: openoffice.org-debian-files: noisy purge script
Package: openoffice.org-debian-files Purging configuration files for openoffice.org-debian-files ... rmdir: `/etc/openoffice': Directory not empty rmdir: `/var/state/openoffice': No such file or directory Unnecessarily chatty, those ought to be suppressed (since they don't appear to be real errors). -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#295451: spamassassin: infinite loop in bayes database handling
Package: spamassassin Severity: important This happens at random intervals: stat64(/home/asuffield/.spamassassin/bayes_toks.expire2054, 0xb580) = -1 ENOENT (No such file or directory) open(/home/asuffield/.spamassassin/__db.bayes_toks.expire2054, O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = -1 EEXIST (File exists) open(/home/asuffield/.spamassassin/__db.bayes_toks.expire2054, O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = -1 EEXIST (File exists) open(/home/asuffield/.spamassassin/__db.bayes_toks.expire2054, O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = -1 EEXIST (File exists) stat64(/home/asuffield/.spamassassin/bayes_toks.expire2054, 0xb580) = -1 ENOENT (No such file or directory) open(/home/asuffield/.spamassassin/__db.bayes_toks.expire2054, O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = -1 EEXIST (File exists) open(/home/asuffield/.spamassassin/__db.bayes_toks.expire2054, O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = -1 EEXIST (File exists) open(/home/asuffield/.spamassassin/__db.bayes_toks.expire2054, O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = -1 EEXIST (File exists) (repeat endlessly) Obviously the lock-and-create logic has gone badly wrong here somewhere. It's got to be something fairly obvious to be that badly wrong... the filenames in the stat() and open() calls don't even match. It doesn't appear to be related to the input data, so it's probably a race condition. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#295451: spamassassin: infinite loop in bayes database handling
On Tue, Feb 15, 2005 at 06:23:21PM -0500, Duncan Findlay wrote: On Tue, Feb 15, 2005 at 10:33:30PM +, Andrew Suffield wrote: Package: spamassassin Severity: important This happens at random intervals: stat64(/home/asuffield/.spamassassin/bayes_toks.expire2054, 0xb580) = -1 ENOENT (No such file or directory) open(/home/asuffield/.spamassassin/__db.bayes_toks.expire2054, O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = -1 EEXIST (File exists) open(/home/asuffield/.spamassassin/__db.bayes_toks.expire2054, O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = -1 EEXIST (File exists) open(/home/asuffield/.spamassassin/__db.bayes_toks.expire2054, O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = -1 EEXIST (File exists) stat64(/home/asuffield/.spamassassin/bayes_toks.expire2054, 0xb580) = -1 ENOENT (No such file or directory) open(/home/asuffield/.spamassassin/__db.bayes_toks.expire2054, O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = -1 EEXIST (File exists) open(/home/asuffield/.spamassassin/__db.bayes_toks.expire2054, O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = -1 EEXIST (File exists) open(/home/asuffield/.spamassassin/__db.bayes_toks.expire2054, O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = -1 EEXIST (File exists) (repeat endlessly) Obviously the lock-and-create logic has gone badly wrong here somewhere. It's got to be something fairly obvious to be that badly wrong... the filenames in the stat() and open() calls don't even match. It doesn't appear to be related to the input data, so it's probably a race condition. Could you provide any configuration files that might be relavent? I've never seen files starting with __db.bayes_toks. Did you change your Bayes database path? Nothing changed except a few scores; anything relating to bayes is the default stuff. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#295451: spamassassin: infinite loop in bayes database handling
On Tue, Feb 15, 2005 at 03:17:00PM -0800, Justin Mason wrote: actually, it's not so simple. stat64(/home/asuffield/.spamassassin/bayes_toks.expire2054, 0xb580) = -1 ENOENT (No such file or directory) this stat is performed by SpamAssassin code; open(/home/asuffield/.spamassassin/__db.bayes_toks.expire2054, O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = -1 EEXIST (File exists) open(/home/asuffield/.spamassassin/__db.bayes_toks.expire2054, O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = -1 EEXIST (File exists) open(/home/asuffield/.spamassassin/__db.bayes_toks.expire2054, O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = -1 EEXIST (File exists) this open is being performed under the covers in libdb. We have no control over this, as far as I know, since it's all hidden underneath DB_File. Oh, fair chance that it just doesn't like being fed an O_EXCL then. That'll be the libdb backup file. I didn't think we used that functionality (journalling, if I recall correctly). We could delete the __db.bayes_toks* files in advance, if that would help? but still, mysterious. what versions of libdb and the perl DB_File module are you using? and what version of SpamAssassin? ii perl 5.8.4-6Larry Wall's Practical Extraction and Report Languag ii spamassassin 3.0.2-1Perl-based spam filter using text analysis ii libdb4.2 4.2.52-18 Berkeley v4.2 Database Libraries [runtime] Those should be all the relevant ones. Happens to be DB_File 1.808. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#295264: php4-auth-pam: completely broken, crashes apache on start
Package: php4-auth-pam Severity: grave Difficult to miss this one. It segfaults on init every time, almost certainly due to botched ZTS handling. I don't even use the damn thing and it wasted 15 minutes of my time figuring out that it was installed and taking out apache. From the peanut gallery: vorlon we rebuilt PHP with ZTS enabled, which changes APIs and ABIs. vorlon php4-auth-pam was rebuilt, but doesn't actually cope properly. vorlon this didn't stop the maintainer from uploading it. infinity asuffield : You're welcome to file the bug. Something along the lines of testing before uploading is nice would be good. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#293932: profile.py has non-free license
On Mon, Feb 07, 2005 at 01:27:55PM +0100, Matthias Klose wrote: debian-legal, how do other packages handle the md5 stuff? Copyright (C) 1991-2, RSA Data Security, Inc. Created 1991. All rights reserved. License to copy and use this software is granted provided that it is identified as the RSA Data Security, Inc. MD5 Message-Digest Algorithm in all material mentioning or referencing this software or this function. License is also granted to make and use derivative works provided that such works are identified as derived from the RSA Data Security, Inc. MD5 Message-Digest Algorithm in all material mentioning or referencing the derived work. RSA Data Security, Inc. makes no representations concerning either the merchantability of this software or the suitability of this software for any particular purpose. It is provided as is without express or implied warranty of any kind. These notices must be retained in any copies of any part of this documentation and/or software. This is the copy of md5.c fished out of the specification. We've seen it before. There are other variations of md5.c, at least one of which has either a BSD or an MIT license, I forget which. Look around, you should find one easily enough. They're more or less equivalent, you may have to fiddle the function names. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Bug#293743: portmap: discards port mappings on stop; start
Package: portmap Severity: important portmap's init script deliberately saves port mappings when invoked with 'restart', but doesn't do it for stop/start. This makes it discard them in non-trivial scenarios. There's no apparent reason not to save them in all cases, given how it breaks everything using sunrpc when this happens. That said, there should still be a way to flush out the mappings on demand. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
