Bug#486813: gnats should build depend on bison, not bison-1.35
IIRC, there were grammatical errors corrected in CVS different than what was in Debian's package. Feel free to try compiling with the newer one. If it works, go ahead and make the dependency change. Otherwise, use the CVS revision of the grammar file. Should work. Chad -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486813: gnats should build depend on bison, not bison-1.35
Likely true, though there were some incompatibilities that 4.1 had with newer bison code. These were fixed in the CVS version of gnats, which should truly be what we're running anyway. If only I had the time to put into GNATS to address these things. Chad -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442221: gnatsd: no PRs match with 'view' access level
The fix for this bug puzzles me a bit. I can apply the patch in order to get things working, but we really should examine why the expression fails on whitespace. This in itself is a bug. It appears to me that the intention is to account and skip whitespace. In practice, as you have found, that is not the case. I'll look more closely at it this weekend. Thanks for the bug report. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#442227: gnatsd: connection refused for 'localhost' in 'gnatsd.host_access'
Thanks for the bug report. I'll look more closely at it this weekend. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#250311: this bug/#250311: ssh: pubkey auth fails between 3.8.1p1-3 and 3.4(woody)
Justin Pryzby [EMAIL PROTECTED] wrote: http://bugs.debian.org/250311 ssh: pubkey auth fails between 3.8.1p1-3 and 3.4(woody) Please see the above URL; Shawn commented on the bug, but the bug number (still) doesn't reach the submitter by default. Is this problem solved? I honestly don't know. It was reported so long ago. The servers that it could have affected have long since been upgraded. I would consider it close-able, even though the bug for those particular versions may still be in effect. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413968: [php-maint] xmlrpc-epi turns out to be libxmlrpc in php
OK, folks. You have the wrong bug report. #413968 is a bug to clamsmtp, and I REALLY don't think PHP is involved here. Please find the correct bug # and start sending emails there. Thank you, Chad (not a PHP guy) -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413968: clamsmtpd fails, error 451
Steve Langasek [EMAIL PROTECTED] wrote: Well, hard to say it's related without actually being able to reproduce the error, but this: add_clamav2group || true means that any errors from trying to add the clamav user to the clamsmtp group on package install are silently ignored. Probably better to propagate the error, then at least this bug report might be debuggable as a package failing to install, instead of a package failing to run. I think this is a good idea. I wasn't real comfortable adding the || true to begin with, but saw other scripts that did this as precedence. Thanks for investigating. I can't see any overt reason why it should have failed, though, so I wonder if this bug should be downgraded regardless. I would have to agree here as well. I will downgrade to normal. Olaf had been sending me emails directly regard this bug report that I could forward to the queue. In any case, I'll take the || true off and upload the package today. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413968: clamsmtpd fails, error 451
Olaf, With some friendly help and prodding from Steve Langeseck, I recognized some logic errors in the postinst script. Frankly, I am surprised no one ran into it earlier. Here's what I surmise was happening. 1. You had installed clamsmtp in the past. 2. You had removed the package with the --purge flag at some point. this removed the clamav user from the clamsmtp group. (NOTE: clamsmtp user and group had not been removed by the --purge.) 3. When you re-installed the package, the postinst script tested for the existence of the clamsmtp user and group. If it found them, it assumed that everything was fine and moved on to the fixperms portion of the script. This skipped the routines to add clamav to the clamsmtp group, adding clamsmtp to the aliases file, and fixing the config file. I've uploaded a new package that doesn't have these flaws. You do not need to re-install the package, as it sounds like you've worked out the bugs with your current installation. I'm not sure why you needed to specify the 127.0.0.1:10025 address in the OutAddress configuration directive. It could be an issue with ipv4 v.s. ipv6. Though, I'm not sure that's something I can handle in a postinst script. It would be possible to change the template config file to include it, however. If you could do some more testing on your platform to confirm this, I would appreciate it. As it doesn't relate to this bug, per se, you could open a new bug report. I know that reportbug isn't a required tool, but it does include some very helpful information regarding your installed environment, including architecture, debconf settings, and package dependencies. I would urge you to consider using it. Thanks! -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413968: clamsmtpd fails, error 451
On Fri, Mar 09, 2007 at 08:17:03AM +0100, Olaf Zaplinski wrote: uid=101(clamav) gid=101(clamav) groups=101(clamav) clamav should belong to clamsmtp. Run this as root: # adduser clamav clamsmtp # /etc/init.d/clamsmtpd stop # strace clamsmtpd 21 | tee clamsmtpd.strace.log The log file is attached also, it is all in one tgz file. I'll look at this in a moment. I do think it's your group permissions though. You say this is a clean install, not an upgrade? -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ signature.asc Description: Digital signature
Bug#413968: fixed in clamsmtp 1.8-3
Steve Langasek [EMAIL PROTECTED] wrote: Um, either the fix is wrong, or the description of the problem is wrong. Pre-Depends are irrelevant to postinst operation, they only matter if you need the other package from the *pre*inst. You're also supposed to discuss Pre-Depends on -devel before adding them... Well, then let's have the ftpmasters drop the package. If that's too late, I'll upload a roll-back. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413968: fixed in clamsmtp 1.8-3
Steve Langasek [EMAIL PROTECTED] wrote: Yes, by the time I get any mail about it, it's too late. :) Roll-back built. Upload pending. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413968: clamsmtpd fails, error 451
Olaf Zaplinski [EMAIL PROTECTED] wrote: result of fresh install: Mar 8 11:04:47 binky postfix/smtpd[14969]: connect from localhost[127.0.0.1] Mar 8 11:04:47 binky postfix/smtpd[14969]: ADCA5471D1A: client=mx1.bmcag.de[62.206.102.78] Mar 8 11:04:47 binky clamsmtpd: 10: clamav error: /var/spool/clamsmtp/clamsmtpd.f59cDl: lstat() failed. ERROR Mar 8 11:04:47 binky clamsmtpd: 10: from=[...], to=[...], status=CLAMAV-ERROR binky:~# l /var/spool/clamsmtp/ total 0 drwxr-x--- 2 clamsmtp clamsmtp 6 Mar 8 11:10 ./ drwxr-xr-x 8 root root 101 Mar 8 10:49 ../ so no permission problem. Could you check a few things? 1) How much space do you have under /var or /var/spool. 2) Could you send a copy of your configuration file with the bug report. 3) Are you sure that the clamav user is part of the clamsmtp group? (run id -a clamav) You should see something like: uid=108(clamav) gid=108(clamav) groups=108(clamav),115(clamsmtp) Finally, could you run this as root? # /etc/init.d/clamsmtpd stop # strace clamsmtpd 21 | tee clamsmtpd.strace.log Send an email, then compress the log and send it to me directly? My guess is that you have a permissions problem with clamav (clamd). Additionally, you can use a clamd.conf file to boost logging to the clamav-daemon application (clamd). -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407817: Two concurrent German translations for clamsmtp
Christian Perrier [EMAIL PROTECTED] wrote: So, would me sending you the whole thing as of Tuesday be OK for you, Chad? Sure. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400520: Bug#407817: Two concurrent German translations for clamsmtp
On Sat, Feb 24, 2007 at 06:23:52PM +0100, Christian Perrier wrote: OK, danke When you all have it figured out, let me know. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ signature.asc Description: Digital signature
Bug#408471: hitting me too
I was so excited to see this package, and so disappointed to be hit by this bug, too. Any ideas or patches that might fix it? I don't know Haskell, but could take a stab at it. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#283273: Patch for the 4.1.0-0.1 NMU
Thanks for your hard work, Christian. I've been pretty swamped at work in my transition from one job to another. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394931: xen-utils-3.0.3-1: Manpages not included
Package: xen-utils-3.0.3-1 Version: 3.0.3-0-1 Severity: normal Tags: patch Manpages that are provided with the source are not included with the utilities. Use perl-doc package at build-time to generate appropriate manpages and dh_manpages to install them in the appropriate locations. diff -urN xen-3.0-3.0.3-0/debian/control xen-3.0-3.0.3-0.new/debian/control --- xen-3.0-3.0.3-0/debian/control 2006-10-23 16:45:06.0 -0500 +++ xen-3.0-3.0.3-0.new/debian/control 2006-10-23 16:33:50.036667796 -0500 @@ -4,7 +4,7 @@ Maintainer: Debian Xen Team [EMAIL PROTECTED] Uploaders: Julien Danjou [EMAIL PROTECTED], Jeremy T. Bouse [EMAIL PROTECTED], Guido Trotter [EMAIL PROTECTED], Bastian Blank [EMAIL PROTECTED] Standards-Version: 3.7.2.0 -Build-Depends: debhelper (= 5.0.37.2), python-dev (= 2.3), libsdl1.2-dev, bcc, dpatch, lsb-release, python-central (= 0.5), linux-support-2.6.18-1 +Build-Depends: debhelper (= 5.0.37.2), python-dev (= 2.3), libsdl1.2-dev, bcc, dpatch, lsb-release, python-central (= 0.5), linux-support-2.6.18-1, perl-doc Build-Depends-Indep: transfig, tetex-bin, tetex-extra, gs-common XS-Python-Version: current diff -urN xen-3.0-3.0.3-0/debian/rules.real xen-3.0-3.0.3-0.new/debian/rules.real --- xen-3.0-3.0.3-0/debian/rules.real 2006-10-23 16:45:06.0 -0500 +++ xen-3.0-3.0.3-0.new/debian/rules.real 2006-10-23 16:44:45.528956410 -0500 @@ -56,6 +56,9 @@ $(STAMPS_DIR)/build-utils_$(ARCH): DIR=$(BUILD_DIR)/build-utils_$(ARCH) $(STAMPS_DIR)/build-utils_$(ARCH): $(STAMPS_DIR)/setup-utils_$(ARCH) $(MAKE) -C $(DIR)/tools XEN_COMPILE_ARCH=$(XEN_ARCH) XEN_TARGET_ARCH=$(XEN_ARCH) XEN_VERSION=$(VERSION)$(ABINAME) + pod2man $(DIR)/docs/man/xend-config.sxp.pod.5 $(DIR)/docs/man/xend-config.sxp.5 \ + $(DIR)/docs/man/xm.pod.1 $(DIR)/docs/man/xm.1 \ + $(DIR)/docs/man/xmdomain.cfg.pod.5 $(DIR)/docs/man/xmdomain.cfg.5 touch $@ install-base: @@ -96,6 +99,9 @@ install-utils_$(ARCH): DH_OPTIONS = -p$(PACKAGE_NAME_UTILS) -p$(PACKAGE_NAME_IOEMU) install-utils_$(ARCH): $(STAMPS_DIR)/build-utils_$(ARCH) dh_testdir + dh_installman $(DIR)/docs/man/xend-config.sxp.5 \ + $(DIR)/docs/man/xm.1 \ + $(DIR)/docs/man/xmdomain.cfg.5 dh_testroot dh_clean -k install -D -m644 debian/xen-utils.NEWS debian/$(PACKAGE_NAME_UTILS)/usr/share/doc/$(PACKAGE_NAME_UTILS)/NEWS -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.18-1-xen-amd64 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391263: monotone: debian/control requires versioned build depends
Package: monotone Version: 0.30-1 Severity: normal Tags: patch Backport attempts for monotone fail not at the 'build-deps' step, rather during the configuration of the software. configure states that boost 1.33.1 is required. Since the control file has no versioned dependencies upon the boost libraries, this will fail to build from source rather than failing to build for lack of dependent packages. This bug currently doesn't prevent monotone from being built on most platforms, it does fail in mixed environments or for backporting efforts. Chad --- debian/control 2006-09-17 04:56:40.0 -0500 +++ debian/control.new 2006-10-05 13:07:57.720274375 -0500 @@ -3,9 +3,9 @@ Priority: optional Maintainer: Shaun Jackman [EMAIL PROTECTED] Build-Depends: cdbs (= 0.4.28), debhelper (= 4.0.0), autotools-dev, - libboost-date-time-dev, libboost-filesystem-dev, - libboost-program-options-dev, libboost-regex-dev, - libboost-test-dev, libboost-dev, texinfo, libz-dev + libboost-date-time-dev(= 1.33.1), libboost-filesystem-dev(= 1.33.1), + libboost-program-options-dev(= 1.33.1), libboost-regex-dev(= 1.33.1), + libboost-test-dev(= 1.33.1), libboost-dev (= 1.33.1), texinfo, libz-dev Standards-Version: 3.7.2.1 Package: monotone -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (50, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.8-3-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Versions of packages monotone depends on: ii libboost-date-time1.3 1.32.0-6 set of date-time libraries based o ii libboost-filesystem1. 1.32.0-6 filesystem operations (portable pa ii libboost-regex1.32.0 1.32.0-6 regular expression library for C++ ii libc6 2.3.2.ds1-22sarge4 GNU C Library: Shared libraries an ii libgcc1 1:3.4.3-13sarge1 GCC support library ii libstdc++51:3.3.5-13 The GNU Standard C++ Library v3 ii zlib1g1:1.2.2-4.sarge.2 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#376189: RFA: cheetah -- text-based template engine and Python code generator
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Arnaud Fontaine [EMAIL PROTECTED] wrote: I'm interested by taking care of this package. I have worked on the previous NMU of cheetah. If you agree, i will retitle this RFA to ITA. First come, first serve. It's yours. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEqI/nDMcLGCBsWv0RAtbjAKDhgaawfpTpk38DR+qBSPF4alUOoACgm7s/ OL7wO0oWnI8sCrlByBzgXcE= =Zy2z -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#376189: RFA: cheetah -- text-based template engine and Python code generator
Package: wnpp Severity: normal I request an adopter for the cheetah package. The package description is: Cheetah can be used as a standalone templating utility or referenced as a library from other Python applications. It has many potential uses, but web developers looking for a viable alternative to ASP, JSP, PHP and PSP are expected to be its principle user group. . This package contains the manpages for command-line scripts and the common package documentation. It does not contain the cheetah scripts or library itself; these are provided by the Python version-specific packages: python2.4-cheetah, python2.3-cheetah, or python2.2-cheetah. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (50, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.8-3-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366759: eggiffy patch
Piotr Ozarowski [EMAIL PROTECTED] wrote: It builds on my machine, why do you think it's broken? Are you doing a pbuilder build? Also, the patch as you wrote it didn't touch SetupTools.py, which re-loaded the distutils.core.setup module. Why didn't I get a copy of your mail? No idea. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366759: version without renaming Egg directory
The patch is broken. I'm betting you haven't tried building this yet. ;-) The real fix would alter SetupTools.py. Again, hold your horses. I'll take a look at it this weekend. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373265: Please update to new python policy
Piotr Ozarowski [EMAIL PROTECTED] wrote: If you don't respond soon I'll start to prepade a NMU for this weekend (see mentioned mails for details) How kind of you. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373265: Please update to new python policy
One word, Piotr: patience. Just today, I get two emails regarding a change in policy, and no more than a few hours later, you tell me that if I don't move my ass, I'll be NMU'ed. Did it ever occur to you, Piotr, that after seeing these emails, I might have actually been working on the package. Already added to the debian/changelog is a succinct Thanks for the broken patch you sent in for 366759: Egg support, which included a nice little BASH'ism and an unnecessary bumping of dependencies for CDBS. Now, you tell me you're going to NMU my package: If you don't respond soon I'll start to prepade a NMU for this weekend (see mentioned mails for details). Class, I tell you. Pure class. You have energy, which can be beneficial. Now, you need a little tact and patience. Why don't you sit back for a while and let me digest the new information before making a decision about how to handle the new packaging requirements. If you had taken a different approach, I wouldn't be so put-off with you right now. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362630: gnobog: Segfaults on amd64
Package: gnobog
Version: 0.4.3-2.1
Severity: grave
Justification: renders package unusable
Gnobog segaults on amd64 sarge. Example output:
$ gnobob
Gnobog-Message: User Home Directory : /home/ccw
Gnobog-Message: Gnobog Working Directory : /home/ccw/.gnobog/
Gnobog-Message: Creating New Bookmarks Object
Gnobog-Message: Creating New Bookmarks Object
Segmentation Fault
$
Attached is the strace for the crash. I've tried this with sarge
xfree86 libraries as well as xorg. Using the ion3 window manager. If
you have any debugging hints (gtk/gdk) that you'ld like me to try, let
me know what they are.
-- System Information:
Debian Release: 3.1
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.15-1-amd64-k8-smp
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ANSI_X3.4-1968) (ignored: LC_ALL
set to C)
Versions of packages gnobog depends on:
ii gdk-imlib11.9.14-16.2imaging library for use with gtk (
ii libart2 1.4.2-19 The GNOME canvas widget - runtime
ii libaudiofile0 0.2.6-6Open-source version of SGI's audio
ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an
ii libdb33.2.9-22 Berkeley v3 Database Libraries [ru
ii libesd0 0.2.35-2 Enlightened Sound Daemon - Shared
ii libglade-gnome0 1:0.17-3 Library to load .glade files at ru
ii libglade0 1:0.17-3 Library to load .glade files at ru
ii libglib1.21.2.10-9 The GLib library of C routines
ii libgnome321.4.2-19 The GNOME libraries
ii libgnomesupport0 1.4.2-19 The GNOME libraries (Support libra
ii libgnomeui32 1.4.2-19 The GNOME libraries (User Interfac
ii libgtk1.2 1.2.10-17 The GIMP Toolkit set of widgets fo
ii libice6 6.9.0.dfsg.1-3bpo1 Inter-Client Exchange library
ii libsm66.9.0.dfsg.1-3bpo1 X Window System Session Management
ii libx11-6 6.9.0.dfsg.1-3bpo1 X Window System protocol client li
ii libxext6 6.9.0.dfsg.1-3bpo1 X Window System miscellaneous exte
ii libxi66.9.0.dfsg.1-3bpo1 X Window System Input extension li
ii libxml1 1:1.8.17-10GNOME XML library
ii xlibs 6.9.0.dfsg.1-4bpo1 X Window System client libraries m
-- no debconf information
execve(/usr/bin/gnobog, [gnobog], [/* 35 vars */]) = 0
uname({sys=Linux, node=lysine, ...}) = 0
brk(0) = 0x527000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2aabf000
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/etc/ld.so.preload, O_RDONLY)= -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=39097, ...}) = 0
mmap(NULL, 39097, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2aac
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/usr/lib/libgnomeui.so.32, O_RDONLY) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\0\273\2..., 640) = 640
fstat(3, {st_mode=S_IFREG|0644, st_size=980528, ...}) = 0
mmap(NULL, 2029728, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x2abc1000
mprotect(0x2ac99000, 1144992, PROT_NONE) = 0
mmap(0x2acc1000, 978944, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0)
= 0x2acc1000
mmap(0x2adb, 2208, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2adb
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/usr/lib/libart_lgpl.so.2, O_RDONLY) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\300\'\0..., 640) = 640
fstat(3, {st_mode=S_IFREG|0644, st_size=62792, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2adb1000
mmap(NULL, 1109728, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x2adb2000
mprotect(0x2adc, 1052384, PROT_NONE) = 0
mmap(0x2aeb2000, 61440, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0)
= 0x2aeb2000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/usr/lib/libgdk_imlib.so.1, O_RDONLY) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0[EMAIL PROTECTED]..., 640) = 640
fstat(3, {st_mode=S_IFREG|0644, st_size=146320, ...}) = 0
mmap(NULL, 1194408, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x2aec1000
mprotect(0x2aee2000, 1059240, PROT_NONE) = 0
mmap(0x2afc1000, 147456, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0)
= 0x2afc1000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/usr/X11R6/lib/libSM.so.6, O_RDONLY) = 3
read(3,
Bug#359300: RM: showeq - Obsolete package. Unofficially maintained upstream.
Package: ftp.debian.org
Severity: normal
Tags: experimental
I sponsored the package upload of showeq to experimental for Bob
Tanner back in 2003. Since then, he's updated and maintained the
package in his own custom Debian archive. He's starting to receive
bugs to this package, which is quite obsolete now. Recent showeq
packages are at 5.3.x instead of 5.0.0.x. I offered to upload the new
package, which he declined stating that the software changes too much.
It would be more of a hassle for me than it's worth, considering that
he already maintains a package outside Debian.
I suggested that he request the package be removed from the Debian
archive, but since I uploaded it, I am placing that request.
I am attaching the email he sent to me regarding this request.
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (50, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-k7
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968)
(ignored: LC_ALL set to C)
--
Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/
assert(expired(knowledge)); /* core dump */
From [EMAIL PROTECTED] Mon Mar 27 12:15:12 2006
X-Envelope-From: [EMAIL PROTECTED] Mon Mar 27 12:15:08 2006
Return-Path: [EMAIL PROTECTED]
X-Original-To: [EMAIL PROTECTED]
Delivered-To: [EMAIL PROTECTED]
Received: from skuld.wookimus.net (localhost [127.0.0.1])
by skuld-10025.wookimus.net (Postfix) with ESMTP id A65DD1293
for [EMAIL PROTECTED]; Mon, 27 Mar 2006 12:15:03 -0600 (CST)
Received: from enchanter.real-time.com (enchanter.real-time.com [208.20.202.11])
by skuld.wookimus.net (Postfix) with ESMTP id 5BD171286
for [EMAIL PROTECTED]; Mon, 27 Mar 2006 12:15:03 -0600 (CST)
Received: from enchanter.real-time.com (gatekeeper.real-time.com
[65.193.16.100])
by enchanter.real-time.com (8.12.10/8.12.10) with SMTP id
k2RIF0tb020956;
Mon, 27 Mar 2006 12:15:00 -0600
Received: (nullmailer pid 8680 invoked by uid 1000);
Mon, 27 Mar 2006 18:15:00 -
From: Bob Tanner [EMAIL PROTECTED]
Organization: Real Time Enterprises, Inc.
To: Chad Walstrom [EMAIL PROTECTED]
Subject: Re: Showeq, debian proper, bug reports
Date: Mon, 27 Mar 2006 12:14:59 -0600
User-Agent: KMail/1.9.1
References: [EMAIL PROTECTED] [EMAIL PROTECTED]
In-Reply-To: [EMAIL PROTECTED]
X-Face:
[3`Nd-[c#{:(C5H=f!}V%z.vnI8`(kLXYY)kAx+,BjX;C=?utf-8?q?diyTVhW=5EDJPm8btBWNCa=0A=09gTn=2E9b=3Ae!?=%[oU0~AzL/G_OrhZZ}5#2V[wjBK$2}_tw9G9h=?utf-8?q?fc=7BSCk=27J8W=7Cz2C8N=2Ekip=26X=0A=09/fO=7E=5BOf=5B?=U')z#%UPo`yuv\t~6UCC|_hVZ9jz7e;*b(3dlatNs$tl2]Pp7KHa/sx3)=?utf-8?q?gK=5F+=0A=09=268JwOl=5C6m?=\K~)J3~f-2K_p]8a=?utf-8?q?=23B5VJZ2pHwS=26-3=3F8=3Dx=2ETu=7Dr/wDgonbjA=5B4z=7E=7B+12=5C?=
=?utf-8?q?=0A=09=2EtxHE=24=5E?=,0Gfnrl
MIME-Version: 1.0
Content-Type: multipart/signed;
boundary=nextPart12169392.7PUjqHTZ9D;
protocol=application/pgp-signature;
micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on skuld.wookimus.net
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham
version=3.0.3
X-Virus-Scanned: ClamAV using ClamSMTP
X-MD5-Checksum: f8a0c78d37ca2685a2c416016bd87a90 -
X-CRM114-Version: 20050415.BlameTheIRS ( TRE 0.7.2 (GPL) ) MF-DAE15AAC [pR:
47.3490]
X-CRM114-Status: Good ( pR: 47.3490 )
Reply-To: [EMAIL PROTECTED]
X-Filed: inbox/. inbox/2006-03/.
--nextPart12169392.7PUjqHTZ9D
Content-Type: text/plain;
charset=iso-8859-6
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
On Monday 27 March 2006 11:42, you wrote:
Since I'm given up on trying to get showeq into debian proper,
what should Ido with these bug reports. They are no longer valid
since they are filedagainst 5.0.0.14 and the latest version if 5.3.
Please ask the ftp maintainers to remove showeq from the servers.
How do I close the bugs filed against the 5.0.0.14? Close might not be th=
e=20
right option.
Is this my bad? =A0Do you want me to sponsor a new version for you? =A0I
can certainly do so.
Nothing to you with you.
Layers of crap.=20
=46irst, is the program should really only be in experimental, it changes s=
o=20
rapidly, that anything else would be a disservice to the debian community.
Second, the changes are deep impacting things, the type of things that yo=
u=20
really find hard to back-port to a stable version.
Third, -I- feel guilty asking you to upload these things since the package=
=20
changes so rapidly, you'd be sponsoring new uploads several times a week.
=46ourth, maintaining a custom repository with some of the tools out there =
isn't=20
difficult and lets me control everything myself without having to burden=20
others.
=2D-=20
Bob Tanner [EMAIL PROTECTED] | Phone : (952)943-8700
http://www.real-time.com, Minnesota, Linux | Fax : (952)943-8500
Key fingerprint =3D AB15 0BDF BCDE 4369 5B42 1973 7CF1 A709 2CC1 B288
Bug#333081: libpam-abl ITP (update)
OK. Note the debug output for pam_abl on my amd64 system: DEBUG: /etc/security/pam_abl.conf: host_db=/var/lib/libpam-abl/hosts.db DEBUG: /etc/security/pam_abl.conf: host_purge=2d DEBUG: /etc/security/pam_abl.conf: host_rule=*:10/1h,30/1d DEBUG: /etc/security/pam_abl.conf: user_db=/var/lib/libpam-abl/users.db DEBUG: /etc/security/pam_abl.conf: user_purge=2d DEBUG: /etc/security/pam_abl.conf: user_rule=!root:10/1h,30/1d Failed users: admin (1) DEBUG: matchperiod(0x50a380, 1, '10/1h,30/1d') DEBUG: count is 10, **rp='/' DEBUG: period is 3600, **rp=',' DEBUG: Checking 10/3600 DEBUG: howmany(3600) = 0 DEBUG: matchperiod(0x50a380, 1, '30/1d') DEBUG: count is 30, **rp='/' DEBUG: period is 86400, **rp='' DEBUG: Checking 30/86400 DEBUG: howmany(86400) = 0 Not blocking root (34) DEBUG: matchperiod(0x50a400, 34, '10/1h,30/1d') DEBUG: count is 10, **rp='/' DEBUG: period is 3600, **rp=',' DEBUG: Checking 10/3600 DEBUG: howmany(3600) = 0 DEBUG: matchperiod(0x50a400, 34, '30/1d') DEBUG: count is 30, **rp='/' DEBUG: period is 86400, **rp='' DEBUG: Checking 30/86400 DEBUG: howmany(86400) = 0 Not blocking Failed hosts: 221.0.185.126 (35) DEBUG: matchperiod(0x50a380, 35, '10/1h,30/1d') DEBUG: count is 10, **rp='/' DEBUG: period is 3600, **rp=',' DEBUG: Checking 10/3600 DEBUG: howmany(3600) = 0 DEBUG: matchperiod(0x50a380, 35, '30/1d') DEBUG: count is 30, **rp='/' DEBUG: period is 86400, **rp='' DEBUG: Checking 30/86400 DEBUG: howmany(86400) = 0 Not blocking So, it lookes like host 221.0.185.126 attempted to break in with 35 attempts, one to admin and 34 to root. My limits are actually quite high given the attack pattern. It's possible that this host spaced the attack out over a few days. I'll have to check the auth logs to verify. Note, though, that admin was accounted for, even though it doesn't exist on the system. $ id admin id: admin: No such user My sshd_config file has UsePAM yes in the last stack, but doesn't have any AllowedUsers or AllowedGroupsspecified and PasswordAuthentication no is set. My pam stack for ssh is: # Standard Un*x authentication. authrequiredpam_abl.so config=/etc/security/pam_abl.conf @include common-auth (Oh, and I take it back. I actually did write up a manpage for the command-line utility, transliterating it from the HTML page provided by upstream. I hadn't gotten to the point of making the pam_abl.so.5 page.) As far as purging is concerned, a cron job can be created to perform the purge on a daily or sub-daily basis. Autopurge isn't necessarily needed. For performance reasons, I wouldn't care to have it do so anyway. A unix-socket daemon that accepts events from the pam_abl.so module might be a good way to add this functionality without incurring a performance/latency hit during authentication. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333081: libpam-abl ITP (update)
Hey, Nicolai. Good to hear that you've got a package up. I packaged my own a while back using CDBS, but didn't go to the extent that you had. I cannot get to mentors for some reason right now to check it out. Regarding libpam_abl's shortcommings, I'm surprised that an autopurge isn't implemented, and I'm equally surprised that it doesn't track failed attempts on known users. I had ran some tests, albeit not extensive, on this and I believe it recorded failed attempts for known users. It would be relatively useless if it didn't. I was also under the impression that it has two types of blocking, host level and user level. By your account, host level blocking isn't working? Again, this would be a very large detriment to the package, making it less than useful. With respect to some of the DD's responses toward blocking failed login attempts, there is some wisdom in using sane parameters when implementing this type of security. However, I do believe it has a place in the stack of tools used to discourage inappropriate behavior. Defense in Depth is a phrase uttered repeatedly at any security courses I've taken. You have at least two DD's now that believe it has a place in the Debian archive. Eric, if you could sponsor the package, that would be great. I personally have no time to take on more packages. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333081: libpam-abl ITP (update)
Nicolai Ehemann [EMAIL PROTECTED] wrote: The recording of failed attempts on hosts and users definetly _is_ working, but as many failed login attempts are made to non-existing users, _these_ attempts are not recorderded in any way (not in hosts nor in users), because the libpam_abl module is simply not reached in the chain. This was not my experience. We should definitely examine your sshd_config setup as well as the order of your pam stack. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333081: [PATCH] Re: ITP: libpam-abl -- PAM module to blacklist hosts/users with many login
I've got a working package built for amd64 and you're free to use it if you wish. Are you still interested in maintaining this one? Chad gzz9nQW9Yd29.gz Description: libpam-abl_0.2.3-1.diff.gz
Bug#333081: [PATCH] #2
Small fix. Removed Build-Depend on cdbs. It's not used in this case. Also attached, dsc file. Chad gzGmXVzDuSqr.gz Description: libpam-abl_0.2.3-1.diff.gz Format: 1.0 Source: libpam-abl Version: 0.2.3-1 Binary: libpam-abl Maintainer: Nicolai Ehemann [EMAIL PROTECTED] Architecture: any Standards-Version: 3.6.1.1 Build-Depends: debhelper (=4.2.32), libdb4.3-dev (=4.3.27), libpam0g-dev(=0.76) Uploaders: Chad Walstrom [EMAIL PROTECTED] Files: fbcf97067e9647fa1d9257d4e6133cba 19000 libpam-abl_0.2.3.orig.tar.gz 9633cc35e306fd8197241de2cdbdd448 3292 libpam-abl_0.2.3-1.diff.gz
Bug#325120: package: libpam-ldap unable to dlopen(/lib/security/pam_ldap.so
Steve Langasek [EMAIL PROTECTED] wrote: Doesn't that indicate that libpam-ldap *does* have an appropriate versioned dependency, which you violated by versioning your local package with an epoch that's not present in the Debian archive? Probably. The shlibs system of shared library handling in Debian depends on monotonically increasing version numbers for packages; representing your library as a newer version of an existing Debian package, when it lacks symbols that have been added in later upstream versions, breaks this constraint, but that doesn't make the package's dependencies incorrect. Make sure the same isn't true for the original submitter. The problem is definitely a library conflict between libldap2 of the era 2.0.23 v.s. the newer libpam-ldap. -- Chad C. Walstrom [EMAIL PROTECTED]247 Gortner Hall http://www.umn.edu/~ccw Help: 612-625-9284 http://cbs.umn.edu/main/ComputingServices Phone: 612-624-2918 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325120: package: libpam-ldap unable to dlopen(/lib/security/pam_ldap.so
Ah, ha! It turns out that this bug is because libpam-ldap in sarge doesn't have appropriate versioned dependencies on libldap2. I had recompiled the openldap2 libraries and server on woody to enable SSL support way back when. Because I used an epoch in the version, it never got upgraded with the rest of the system to sarge. Still, because libpam-ldap doesn't have an appropriate versioned dependency, it didn't generate a conflict when it was installed. Why the older version in sarge worked with openldap2 v2.0.23 libraries, I do not know. It may have something to do with activation of threading and reliance on the reentrant versions of the ldap library. -- Chad C. Walstrom [EMAIL PROTECTED]247 Gortner Hall http://www.umn.edu/~ccw Help: 612-625-9284 http://cbs.umn.edu/main/ComputingServices Phone: 612-624-2918 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#242236: fixed with #248125?
Mickael Marchand [EMAIL PROTECTED] wrote: I do not seem to be able to reproduce this bug with debian sarge :) (openssh 3.8.1p1-8.sarge.4) I believe the bug can be closed now. I'll do some more testing when I get to work tomorrow. We have a dual AMD Athlon server running a 2.6.8 kernel with and updated sarge binary of SSH (or so I thought). I have to rely upon a cron job to match and kill notty sshd sessions on the server to keep the load reasonable. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324617: mozilla-firefox: side-bar segfaults
Package: mozilla-firefox Version: 1.0.4-2sarge2 I've also gotten mozilla to reliably crash when trying to view the sidebar, regardless if it's history or bookmarks. I removed mozilla-tabextensions (1.14.2005040701-1) and it quit crashing. So, this bug should probably be refiled against mozilla-tabextensions. Test it to make certain, though. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323805: libpam-ldap: Incorrect password does not prompt again
Package: libpam-ldap Version: 178-1 Severity: minor If one uses the use_first_password option to pam_ldap.so, an incorrect password errors out with the following message instead of prompting for a password again. [09:23:07] [EMAIL PROTECTED] (531)$ sudo ls Password: sudo: pam_authenticate: Authentication service cannot retrieve authentication info. This causes some minor invonceniences and confusion with users on multiple platforms. ssh clients, for example, loose connection immediately rather than prompting for the password again. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-k7-smp Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Versions of packages libpam-ldap depends on: ii debconf 1.4.30.13Debian configuration management sy ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libldap21:2.0.23-6.3.0.1 OpenLDAP libraries. ii libpam0g0.76-22 Pluggable Authentication Modules l -- debconf information: * shared/ldapns/base-dn: dc=cbd,dc=umn,dc=edu * libpam-ldap/dbrootlogin: true libpam-ldap/override: false * shared/ldapns/ldap-server: 127.0.0.1 * libpam-ldap/pam_password: clear libpam-ldap/binddn: cn=proxyuser,dc=example,dc=net * libpam-ldap/rootbinddn: cn=admin,dc=example,dc=net * shared/ldapns/ldap_version: 3 * libpam-ldap/dblogin: false -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#244110: The state of ITP: python-utidylib -- Bindings for libtidy that uses the python-ctypes
Igor Stroh [EMAIL PROTECTED] wrote: what's the current state of this packaging effort? I'd like to have it in the archive, so please raise your voice :) If there's still the need for a sponsor - I'm all yours. I don't have time to sponsor another NM/package, and I haven't kept up w/python-utidylib. If you're interested, my arch repository has a working package availabe. If noone responds within a reasonable amount of time (say, a week) I'm going to take over this ITP. Go for it. I've attached the diff I had, though I think with CDBS, one can now unpack zip files. You wouldn't have to repack the original software, and people could compare it's MD5 sum against the one found on berlios' site. gzawLDSokBdP.gz Description: utidylib_0.2-1.diff.gz
Bug#322359: gnats: FTBFS: unpacking fails - Please do not use a version number ending with '-0'
Andreas Jochens [EMAIL PROTECTED] wrote: On 05-Aug-10 07:05, Chad Walstrom wrote: reassign 322359 dpkg 1.13.10 Andreas Jochens [EMAIL PROTECTED] wrote: This is because the new dpkg does not accept a version ending with '-0'. Well then. Wouldn't that be a bug with dpkg? ;-) I understand that this was changed intentionally. Policy seems to require that the numbers start with '-1'. Require is hardly true. If I recall correctly, and perhaps I'm a geezer in this respect, policy recommends that debian package numbers start with -1. It doesn't require that they do. In fact, tools have been designed to accommodate both 0 and 1 as the initial version. We do live in a computer world where ordinal numbers are a rule, not an exception. If the debian-policy makers enforce the no -0 rule, I will upload a new version. But until I'm told otherwise, I'll continue to use -0 as my initial package versions. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#322237: kernel-image-2.6.8-11-amd64-k8-smp: [PATCH] Panic on ipt_recent - 32bitism
Package: kernel-image-2.6.8-11-amd64-k8-smp
Severity: important
While using the ipt_recent kernel module to stop SSH bruteforce attacks,
the kernel panics on a 32-bitism. This crash can occur at any time.
---8---
Unable to handle kernel paging request at ff5e3000 RIP:
801c8a20{__memset+32}
PML4 3e8063 PGD 1ff9067 PMD 365ae067 PTE 0
Oops: 0002 [1] SMP
CPU 0
Modules linked in: ipv6 ipt_REJECT ipt_LOG ipt_state ipt_pkttype ipt_recent
ipt_iprange ipt
Pid: 0, comm: swapper Not tainted 2.6.8-11-amd64-k8-smp
RIP: 0010:[801c8a20] 801c8a20{__memset+32}
RSP: 0018:80392450 EFLAGS: 00010216
RAX: RBX: 07f8 RCX: 0006
RDX: RSI: RDI: ff5e3000
RBP: ff5dd000 R08: R09: ff5e2fe0
R10: ff5e4000 R11: ff5e6000 R12: 0059
R13: ff5df000 R14: 8b905486 R15: 0059
FS: 002a958ab640() GS:803e2e40() knlGS:
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: ff5e3000 CR3: 00101000 CR4: 06e0
Process swapper (pid: 0, threadinfo 803e6000, task 802ef6c0)
Stack: a01f38f0 a01a4f1d ff5e6000 ff5e4000
0206 7ec35980 4059 ff5f2418
0001005be582 803925d0
Call Trace:IRQ a01f38f0{:ipt_recent:match+1728}
a01a4f1d{:ip_conntra
a019c28d{:ip_tables:ipt_do_table+605}
8024e91a{nf_iterate+90}
8025ed50{ip_local_deliver_finish+0}
8024ed87{nf_hook_slow+135}
8025ed50{ip_local_deliver_finish+0}
8025f160{ip_local_deliver+5
8025f3b3{ip_rcv_finish+579}
8025f170{ip_rcv_finish+0}
8025f170{ip_rcv_finish+0} 8024edca{nf_hook_slow+202}
8025f170{ip_rcv_finish+0} 8025f89d{ip_rcv+1165}
80245f1d{netif_receive_skb+461}
8010fbd5{ret_from_intr+0}
a00f73b9{:tg3:tg3_poll+1705}
80246114{net_rx_action+132}
801391e3{__do_softirq+83} 80139275{do_softirq+53}
801125a1{do_IRQ+321} 8010d980{default_idle+0}
8010fbd5{ret_from_intr+0} EOI
802a5399{thread_return+41}
8010d9a0{default_idle+32} 8010da2a{cpu_idle+26}
803e96fb{start_kernel+507} 803e9203{_sinittext+515}
Code: f3 48 ab 44 89 c1 f3 aa 4c 89 c8 c3 66 66 66 90 ff c9 48 89
RIP 801c8a20{__memset+32} RSP 80392450
CR2: ff5e3000
0Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
0Rebooting in 30 seconds..
---8---
The blog entry below details the bug and supplies the patch:
http://blog.blackdown.de/2005/05/09/fixing-the-ipt_recent-netfilter-module/
http://blog.blackdown.de/static/kernel/ipt_recent-fix.patch
Here is the patch for 2.6:
---8---
Fixing the ipt_recent Netfilter Module
(cf.
http://blog.blackdown.de/2005/05/09/fixing-the-ipt_recent-netfilter-module/)
I've had some ipt_recent rules acting strangely after an uptime of
about 25 days. The problem is reproducible in the 5 minutes before
the first jiffies roll-over right after booting too.
The problem is caused by the jiffies comparision which doesn't work
like intended if one of the last hit was more than LONG_MAX seconds
again or if the table of last hits contains empty slots and jiffies
is LONG_MAX.
This patch fixes the problem by using get_seconds() instead of
jiffies. It also fixes some 64-bit issues.
Signed-off-by: Juergen Kreileder [EMAIL PROTECTED]
diff --exclude=arch --exclude-from=Documentation/dontdiff -ur
../linux-2.6.12-rc3-mm3/include/linux/netfilter_ipv4/ipt_recent.h
./include/linux/netfilter_ipv4/ipt_recent.h
--- ../linux-2.6.12-rc3-mm3/include/linux/netfilter_ipv4/ipt_recent.h
2005-03-02 08:38:10.0 +0100
+++ ./include/linux/netfilter_ipv4/ipt_recent.h 2005-05-09 14:50:40.0
+0200
@@ -2,7 +2,7 @@
#define _IPT_RECENT_H
#define RECENT_NAMEipt_recent
-#define RECENT_VER v0.3.1
+#define RECENT_VER v0.3.2
#define IPT_RECENT_CHECK 1
#define IPT_RECENT_SET2
diff --exclude=arch --exclude-from=Documentation/dontdiff -ur
../linux-2.6.12-rc3-mm3/net/ipv4/netfilter/ipt_recent.c
./net/ipv4/netfilter/ipt_recent.c
---
Bug#321319: libpam-krb5: Password from PRINCIPLE: causes Fugu to fail to log in
Package: libpam-krb5 Severity: minor This may be true for other GUI tools for SSH commandline utilities, but Fugu (a Mac OS X client) fails to log in with ssh2 if I use libpam-krb5 for authentication. If you take out the for PRINCIPLE segment of the string, everything works as expected. The user should not need to see the PRINCIPLE information in the password prompt, since the user is usually responsible for typing it in as the username or using the default in /etc/krb5.conf. This bug does not effect the general usefulness of the tool for user-interactive sessions. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-k7 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315596: digitemp - Still some formatting problems
Package: digitemp Verson: 3.4.0-1 [EMAIL PROTECTED] wrote: Could you test the original tarball? Tested. Sorry it took me so long. The original and your package behave the same. Note the '-o2' and '-o3' output in the session log belog. They correctly override the default format now, but if I understand the explanation in the manpage correctly, the output should be one line per sensor, with the enumerated sensor label being first. Command 505 would then look like this: DigiTemp v3.4.0 Copyright 1996-2005 by Brian C. Lane GNU Public License v2.0 - http://www.digitemp.com 0 20.34 1 27.88 The one that's important to me, though is the '-o FORMAT STRING'. This one is still not working. (See 507) - 8 501$ digitemp_DS9097U -s /dev/ttyS0 -w DigiTemp v3.4.0 Copyright 1996-2005 by Brian C. Lane GNU Public License v2.0 - http://www.digitemp.com Turning off all DS2409 Couplers .. Devices on the Main LAN 264D906E006C : DS2438 Temperature, A/D Battery Monior 2647EE6D00E4 : DS2438 Temperature, A/D Battery Monior 502$ digitemp_DS9097U -s /dev/ttyS0 -a DigiTemp v3.4.0 Copyright 1996-2005 by Brian C. Lane GNU Public License v2.0 - http://www.digitemp.com 503$ digitemp_DS9097U -s /dev/ttyS0 -i DigiTemp v3.4.0 Copyright 1996-2005 by Brian C. Lane GNU Public License v2.0 - http://www.digitemp.com Turning off all DS2409 Couplers .. Searching the 1-Wire LAN 264D906E006C : DS2438 Temperature, A/D Battery Monior 2647EE6D00E4 : DS2438 Temperature, A/D Battery Monior ROM #0 : 264D906E006C ROM #1 : 2647EE6D00E4 Wrote .digitemprc 504$ digitemp_DS9097U -s /dev/ttyS0 -a DigiTemp v3.4.0 Copyright 1996-2005 by Brian C. Lane GNU Public License v2.0 - http://www.digitemp.com Jul 28 13:00:35 Sensor 0 C: 20.25 F: 68.45 H: 24% Jul 28 13:00:36 Sensor 1 C: 27.81 F: 82.06 H: 0% 505$ digitemp_DS9097U -s /dev/ttyS0 -a -o2 DigiTemp v3.4.0 Copyright 1996-2005 by Brian C. Lane GNU Public License v2.0 - http://www.digitemp.com 0 20.34 27.88 506$ digitemp_DS9097U -s /dev/ttyS0 -a -o3 DigiTemp v3.4.0 Copyright 1996-2005 by Brian C. Lane GNU Public License v2.0 - http://www.digitemp.com 0 68.51 82.17 507$ digitemp_DS9097U -s /dev/ttyS0 -a -o Sensor: %S F: %Fs DigiTemp v3.4.0 Copyright 1996-2005 by Brian C. Lane GNU Public License v2.0 - http://www.digitemp.com Jul 28 13:02:50 Sensor 0 C: 19.81 F: 67.66 H: 24% Jul 28 13:02:50 Sensor 1 C: 28.00 F: 82.40 H: 0% 508$ cat .digitemprc TTY /dev/ttyS0 READ_TIME 1000 LOG_TYPE 1 LOG_FORMAT %b %d %H:%M:%S Sensor %s C: %.2C F: %.2F CNT_FORMAT %b %d %H:%M:%S Sensor %s #%n %C HUM_FORMAT %b %d %H:%M:%S Sensor %s C: %.2C F: %.2F H: %h%% SENSORS 2 ROM 0 0x26 0x4D 0x90 0x6E 0x00 0x00 0x00 0x6C ROM 1 0x26 0x47 0xEE 0x6D 0x00 0x00 0x00 0xE4 -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318119: mercurial: Please reduce dependence upon newer cdbs (easier backporting)
Vincent Danjean [EMAIL PROTECTED] wrote: I use quilt to manage patches of several projects. I'm not going to begrudge your choice in management tools. Quilt seems quite capable, certainly. The decision to require more advanced patching tools for a BUILD environment is subjective, I feel, to the complexity of the patches themselves. If you were packaging Xorg or XFree86, then I wouldn't have raised any concern. However, since the patching required is quite simple, why elevate the requirements for the actual build environment? In requiring someone to backport cdbs (which arguably isn't difficult), you also require them to backport all of its dependencies (which includes quilt) and their depenedencies. Soon, you're building a tree of packages. For Xorg, this could be seen as a necessity, but for mercurial, it is arguably overkill. In any case, it was a wishlist request and nothing more. I could just as easily strip the dependencies out and make my own custom package, but I really feel that it shouldn't be necessary. Do as ye will. ;-) (It looks like mercurial has just gotten a booster shot and now has quilt-like capabilities as well.) -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318481: CAN-2005-2180 gen-index file overwrite vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 tags 318481 woody quit Not vulnerable in gnats/gnats-user = 4.0. Vulnerable in gnats/gnats-user 4.0. drwxr-xr-x 53 root root 12288 Jul 14 09:32 /usr/lib drwxr-xr-x2 root root4096 Mar 7 20:23 /usr/lib/gnats - -rwxr-xr-x1 root root3260 Mar 7 20:20 /usr/lib/gnats/at-pr - -rwxr-xr-x1 root root5317 Mar 7 20:20 /usr/lib/gnats/check-db - -rwxr-xr-x1 root root2865 Mar 7 20:20 /usr/lib/gnats/delete-pr - -rwxr-xr-x1 root root 142512 Mar 7 20:21 /usr/lib/gnats/gen-index - -rwxr-xr-x1 root root 142544 Mar 7 20:21 /usr/lib/gnats/gnats-pwconv - -rwxr-xr-x1 root root 167928 Mar 7 20:21 /usr/lib/gnats/gnatsd - -rwxr-xr-x1 root root3105 Mar 7 20:20 /usr/lib/gnats/mail-query - -rwxr-xr-x1 root root1739 Mar 7 20:20 /usr/lib/gnats/mkcat - -rwxr-xr-x1 root root2766 Mar 7 20:20 /usr/lib/gnats/mkdb - -rwxr-xr-x1 root root 143336 Mar 7 20:21 /usr/lib/gnats/queue-pr - -rwxr-xr-x1 root root1898 Mar 7 20:20 /usr/lib/gnats/rmcat - -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC2A9PDMcLGCBsWv0RArctAJ9XzppHiOOZjOzFu+ImaUyEvkHHYACeMt7D 7iVpqci+6hzQrvJnXYQ0Ijc= =cGqF -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318119: mercurial: Please reduce dependence upon newer cdbs (easier backporting)
Package: mercurial Version: 0.6-1 Severity: wishlist There is very little reason to use the cdbs patchsys-quilt.mk file. simple-patchsys works just fine for what you need it to do. Switching to a simpler tool will allow you to reduce the version dependency to something obtainable on sarge, making backports much easier. Personally, I try to construct control, build, and maintainer scripts so that you can backport one version (the current stable version). There is nothing in the mercurial software package that requires unstable tools, so why make the packaging process dependent upon unstable? -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-k7 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315596: digitemp: output format not honored
[EMAIL PROTECTED] wrote: could you try them? So far, it looks like it's failing for me when using purely command-line options. With an RC file, I'm getting logging output, but when I don't specify one, I do not. I have not tried to customize the RC file formats yet. I'll spend some time writing up a full report later today or tomorrow. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315596: digitemp: output format not honored
=?iso-8859-15?q?Jes=FAs_Roncero?= [EMAIL PROTECTED] wrote: Does that happens with both the original tar.gz from digitemp.com and the deb package I made or only with one of them? (in case you tested the original tar.gz) I downloaded the original tarball but used your *.dsc/diff.gz files to create the deb. I will compile the original tarball and test tomorrow. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315596: digitemp: output format not honored
=?iso-8859-1?q?Jes=FAs_Roncero?= [EMAIL PROTECTED] wrote: I have some preliminary packages at http://roncero.org/digitemp/ Would you mind trying them out and tell me about the results? Any problem or suggestions. I still need to fine tune them a little bit, but would like you to test them. Everything seems to work ok here. I'll test them out on Tuesday or Wednesday at work. Have a great 4th! -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315596: digitemp: output format not honored
[EMAIL PROTECTED] wrote: Could you do some more testing calling digitemp directly as the digitemp user? Just to discard sudo has nothing to do with this (I guess it doesn't!). Yeah, the digitemp user I created was a system user w/o a password or shell. It won't run anything w/o sudo. ;-) I only did that to show you what I was doing from a cron job. Brian wrote: He's using a DS2438 sensor (note the H: in his output). The formatting options don't yet work right with the DS2438 because I haven't come up with a 'clean' way to implement it. I'll take a look at it this weekend and see if I can finally implement something that makes sense. Yeah, I was a bit surprised by the humidity reading, myself. I bought the Link45 Temp kit from ibuttonlink.com:: DT-LT Kit Just what you need to get started monitoring temperatures. An iButtonLink Link45, Two MultiSensor MS-Ts and two, six (6) foot long Cat5E cables. On the description, it only reads as a Temp sensor, not a temp and humidity sensor. Alas, it is reporting humidity, so I may be wrong. ;-) Here's the output from '-w':: $ sudo -u digitemp digitemp_DS9097U -s /dev/ttyS0 -w DigiTemp v3.3.2 Copyright 1996-2004 by Brian C. Lane GNU Public License v2.0 - http://www.brianlane.com Turning off all DS2409 Couplers .. Devices on the Main LAN 264D906E006C : DS2438 Temperature, A/D Battery Monior 2647EE6D00E4 : DS2438 Temperature, A/D Battery Monior Again, I may be wrong, but I don't think this model has a battery Monior (sic!). Jesus wrote: Ok. Keep me informed if you fix it. I'll then prepare a new package and send it to my sponsor. Sweet. I don't have time myself to dig into the code. Life is very busy at work and home. :( The boss wants a munin plugin for the temp sensors before too long, though we're both content with the log file for the time being. Being able to customize the output of the digitemp call would make it very, very easy to write the plugin. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315596: digitemp: output format not honored
Package: digitemp Version: 3.3.2-2 Severity: normal When running digitemp_DS9097U with the commandline option to specify the output format, digitemp outputs the default format instead. $ sudo -u digitemp digitemp_DS9097U -a -o 'Sensor %s %.2F' DigiTemp v3.3.2 Copyright 1996-2004 by Brian C. Lane GNU Public License v2.0 - http://www.brianlane.com Jun 23 15:22:30 Sensor 0 C: 15.34 F: 59.62 H: 0% Jun 23 15:22:31 Sensor 1 C: 25.88 F: 78.58 H: 0% When selecting one of the numeric options for '-o', the number 0 is printed, and then the default format is once again used. $ sudo -u digitemp digitemp_DS9097U -a -o 2 DigiTemp v3.3.2 Copyright 1996-2004 by Brian C. Lane GNU Public License v2.0 - http://www.brianlane.com 0Jun 23 15:25:31 Sensor 0 C: 15.38 F: 59.67 H: 0% Jun 23 15:25:32 Sensor 1 C: 25.78 F: 78.41 H: 0% This could use some cleanup. The default format is certainly parseable, but it would be far easier to specify a format when using digitemp in scripts. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-k7-smp Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Versions of packages digitemp depends on: ii libc62.3.2.ds1-22GNU C Library: Shared libraries an ii liblockdev1 1.0.1-6 Run-time shared library for lockin ii libusb-0.1-4 2:0.1.10a-9.sarge.1 userspace USB programming library -- no debconf information -- Chad C. Walstrom [EMAIL PROTECTED] 247 Gortner Hall Asst. Coordinator of IT Help: 612-625-9284 CBS Computing Services, UMNPhone: 612-624-2918 -- Chad C. Walstrom [EMAIL PROTECTED] 247 Gortner Hall Asst. Coordinator of IT Help: 612-625-9284 CBS Computing Services, UMNPhone: 612-624-2918 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315599: digitemp: BASHism in debian/rules
Package: digitemp
Severity: minor
You have a BASHism in debian/rules:
mkdir -p build-serial/{src,userial/ds9097,userial/ds9097u}
The {} expansion is not POSIX standard. For example, if dash were the
default shell for the build environment, this would FTBFS. A simple
test to demonstrate this is to run echo {blee,blah} in a BASH and in
dash. BASH will output blee blah, and dash will output {blee,blah}.
-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-k7
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ANSI_X3.4-1968) (ignored: LC_ALL
set to C)
--
Chad C. Walstrom [EMAIL PROTECTED] 247 Gortner Hall
Asst. Director of ITHelp: 612-625-9284
CBS Computing Services, UMNPhone: 612-624-2918
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309648: Should we reopen the bug?
reopen 309648 = thanks Absolutely. It should be reopened for sarge. I should not have put the Closed: line in the changelog. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309348: Please migrate clamsmtp_1.4.1-0 to Sarge
Package: clamsmtp Version: 1.4-0 Severity: serious Tags: sarge fixed The upstream version of clamsmtp, 1.4.1, fixed a bug critical to the usability of the clamsmtp package. The debian package (1.4.1-0) has been in unstable for over 22 days and has had no further bugs (including RC bugs) filed against it. Please consider pushing this to sarge. Nielsen, the author of Clamsmtp, describes the problem in this post:: http://sourceforge.net/mailarchive/message.php?msg_id=11483769 Ive released new point versions of ClamSMTP and ProxSMTP. The last ones had a nasty bug which in some cases resulted in dropped connections and garbage being sent to the recipient server. Apologies to all those who were inconvenienced. And thanks to those ones who pointed this problem out. Cheers, Nate ...[snip]... ClamSMTP Users: - --- If you were running ClamSMTP 1.4 and had a line in your configuration file like this (in other words added *no* scan header): Header: Users using the default configuration file, or who dont have a line like the above in their configuration file are not affected. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ signature.asc Description: Digital signature
Bug#308835: [PATCH] codeville_0.1.12-0 ready
Package: codeville Severity: wishlist Tags: patch I've rolled up the 0.1.12-0 Debian version (patch attached). I've changed the Maintainer field in the debian/control file to you, and added an Uploaders field with my name in it (entirely your prerogative to keep or discard). 0.1.11-0 is in experimental, and the 0.1.12 was released two days after I made that upload (though it was only accepted on the 10th, probably because 0.1.11 was DFSG-compliant). The only lintian/linda warnings we get that are worth paying attention to is the manpage ones, but since the package is in experimental, I figure we can ignore those for now. I've committed the changes to my arch repository, as usual, so that's available if you wish to use it. Anyway, I figure the next upload is probably yours, so here's the patch. The signed dsc is also attached so you can compare signatures of the the diff and upstream tarball (which I simply renamed to Debian's naming conventions). I've got this version installed on my machine and it appears to install well and run as expected. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ codeville_0.1.12-0.diff.gz Description: Binary data -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.0 Source: codeville Version: 0.1.12-0 Binary: codeville Maintainer: Michael Janssen [EMAIL PROTECTED] Architecture: all Standards-Version: 3.6.1.1 Build-Depends: debhelper (= 4.1.38), cdbs (= 0.4.27), python-dev (=2.3), python-dev ( 2.4) Uploaders: Chad Walstrom [EMAIL PROTECTED] Files: 665e370a7f55b70ee54c987f04273cce 88209 codeville_0.1.12.orig.tar.gz 3279b0c151d8f65191b23724d2a5a126 10202 codeville_0.1.12-0.diff.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCg38ADMcLGCBsWv0RApREAKCpIuykn5J8PatZV38pa4NY+0UQNwCgtmHC gpBFQATEk3MKR0ABmlPivbk= =zLqY -END PGP SIGNATURE- signature.asc Description: Digital signature
Bug#280209: ITP: codeville...
On Tue, May 10, 2005 at 04:51:29PM -0500, Michael Janssen wrote: It's okay - I am actually in a waiting state because the next release of Codeville will be released under BSD, so it will be a candidate for main instead of having to go into non-free. I'll be packaging the new version when it gets released. (Okay, that's apparently already out. I was in England until thursday so) As a sidenote, I actually have been using the old dh_make way and your mention of cdbs as a system is very interesting, thanks for that. OK. Looks like I just got confirmation that codeville 0.1.10 was uploaded to experimental. I did upload version 0.1.11 to the FTP masters as well, and you can access my GNU Arch repository at http://arch.debian.org/arch/private/chewie/debian/. Obviously, all you need are the diffs, but it's there if you wish to use it. If you would like a co-maintainer, I would be happy to help. Otherwise, feel free to nuke my name from the Maintainer field and upload your own version. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ signature.asc Description: Digital signature
Bug#280209: [PATCH] Re: Debian experimental package pending upload
On Mon, May 02, 2005 at 05:43:09PM -0500, Chad Walstrom wrote: The diff is attached. Apparently it wasn't. Oh well. I'll submit it to the BTS, which can be browsed via http://bugs.debian.org/280209 -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ signature.asc Description: Digital signature
Bug#280209: [PATCH] Re: Debian experimental package pending upload
Here's the patch. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ codeville_0.1.10-0.diff.gz Description: Binary data signature.asc Description: Digital signature
Bug#280209: Debian experimental package pending upload
In response to the Request For Package (RFP) #280209, [1]_ I've hacked up a quick codeville package. The diff is attached. There are some debian-legal matters concerning Open Source License v2.0 (and even v2.1), so it'll probably end up in non-free (not that I agree with these legal banterings at all). We'll see what the ftp masters do with it. I recall seeing a note on the codeville.org website that the next release may be under a BSD-style license. Is this still applicable? I don't have a LOT of time to maintain the package, so I would be perfectly happy to co-maintain it with someone (anyone interested)? The codeville package is installed against Python 2.3, the default python package for Sarge. If you feel that there should be further restrictions to version dependency or if you would like version specific packages, let me know. (Personally, I think it's overkill unless you're making module packages.) References == .. [1] http://bugs.debian.org/280209 -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ signature.asc Description: Digital signature
Bug#307352: python2.4-cheetah: errorCatcher fails
On Mon, May 02, 2005 at 01:39:40PM -0500, Paul Jimenez wrote: Existing cheetah code now causes a traceback: ... Looking at the code, it looks as if *ErrorCatcher methods might have been moved from Parser.py to Compiler.py without the calls to them in eatErrorCatcher getting fixed. Did you recompile your templates? If not, please do so. There were changes to the compiled python code that are not portable from 0.9.15. Check the README.Debian and NEWS files for details. Additionally, here is a recent post on the cheetahtemplate-discuss about ErrorCatcher:: From: Tavis Rudd [EMAIL PROTECTED] Re: Security hole in Cheetah? 2005-04-26 14:10 ErrorCatcher is a debugging tool and was never meant for use in production systems. What would lead you to have NotFound errors in production? On Tuesday 26 April 2005 02:20, Brian Bird wrote: If nobody uses errorCatcher, perhaps theres a better way to achieve what Im trying to do? I want any $placeholder variable to be replaced by a blank string if it cannot be found in the namespaces, instead of raising a NotFound exception. Ive done some digging and the best suggestion seems to be to put something like th ...snip... http://sourceforge.net/mailarchive/message.php?msg_id=11589131 -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ signature.asc Description: Digital signature
Bug#285053: sudo keeps complaining about timestamp being too far in the future
Here is the reply from Todd Miller of the sudo team. http://www.courtesan.com/bugzilla/show_bug.cgi?id=175 Sounds like there is a bug in the debian utimes() then. sudo calls utimes() with a NULL pointer to update the times on the timestamp file. The only time it passes a non-NULL value is for sudo -k. As a workaround you may be able to just force sudo to use utime() instead by setting ac_cv_func_utimes=no in your environment before running configure. It is also possible that Debia Bug#202243 is relevant here but that should have been fixed a long time ago. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ signature.asc Description: Digital signature
Bug#303254: munin-node: irqstats error on sparc64
Package: munin-node Version: 1.2.2-3 Severity: normal String matching isn't geared for what sparc reports, evidently... $ grep 'irqstats' /var/log/munin/munin-node.log | uniq Argument su(mouse):7ea, isn't numeric in addition (+) at /etc/munin/plugins/irqstats line 62, $in line 2. Argument SABRE isn't numeric in addition (+) at /etc/munin/plugins/irqstats line 62, $in line 7. Argument UE:7ee, isn't numeric in addition (+) at /etc/munin/plugins/irqstats line 62, $in line 7. $ cat /proc/interrupts 0: 651818769 timer:dead 4: 23972191 su(mouse):7ea, ide0:7e0 5: 70473232 eth0:7e1 6: 19241735 eth1:7d8 9: 3354 su(kbd):7e9 12: 0 serial(sab82532):7eb 15: 0 SABRE UE:7ee, SABRE CE:7ef, SABRE PCIERR:7f0, power:7e5 -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (998, 'testing') Architecture: sparc (sparc64) Kernel: Linux 2.4.24-sparc64 Locale: LANG=C, LC_CTYPE=en_US.ISO-8859-1 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Versions of packages munin-node depends on: ii libnet-server-perl0.87-3 An extensible, general perl server ii perl 5.8.4-8Larry Wall's Practical Extraction ii procps1:3.2.1-2 The /proc file system utilities -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302220: postfix_mailstats: overzealous regex for rejects
Package: munin-node
Version: 1.2.2-3
Severity: normal
The postfix_mailstats plugin uses a coarse perl regex to attempt to
match reject codes in the mail log.
231 }
232 elsif ($line =~ /reject: \S+ \S+ \S+ (\S+)/)
233 {
234 $rejects-{$1} ++;
If you will note by the following log entries, postfix rejects messages
from different applications with different message formats. The first
listed is from the cleanup daemon rejecting a message based on
mime_header regex matching.
Mar 29 17:20:43 hostname postfix/cleanup[15643]: 29CD210067: reject: header
Content-Type: application/x-zip-compressed; name=message.zip from
c-67-167-108-192.client.comcast.net[67.167.108.192]; from=[EMAIL PROTECTED]
to=[EMAIL PROTECTED] proto=SMTP helo=localhost: Mail filters have
determined that your email appears to be infected with the Bagle virus. Email
[EMAIL PROTECTED] if you feel this REJECT was in error.
Here's a reject from the smtpd daemon. This is what the coarse regex
above is attempting to match.
Mar 29 17:32:15 hostname postfix/smtpd[17441]: NOQUEUE: reject: RCPT from
hsdbsc69-11-111-36.sasknet.sk.ca[69.11.111.36]: 554 Service unavailable; Client
host [69.11.111.36] blocked using cbl.abuseat.org; Blocked - see
http://cbl.abuseat.org/lookup.cgi?ip=69.11.111.36; from=[EMAIL PROTECTED]
to=[EMAIL PROTECTED] proto=ESMTP helo=hsdbsc69-11-111-36.sasknet.sk.ca
I propose the following change to line 232::
232 elsif ($line =~ /postfix\/smtpd.*reject: \S+ \S+ \S+ (\S+)/)
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (990, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-k7-smp
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ANSI_X3.4-1968) (ignored: LC_ALL
set to C)
Versions of packages munin-node depends on:
ii libnet-server-perl0.87-3 An extensible, general perl server
ii perl 5.8.4-8Larry Wall's Practical Extraction
ii procps1:3.2.1-2 The /proc file system utilities
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301518: clamsmtp: Plain installation on sarge fails with /var/lib/ucf/cache not existing
On Sun, Mar 27, 2005 at 09:38:23PM +0300, Art?ras ?lajus wrote: This is not a bug in program, this is bug in packaging. The error is produced by dpkg in preconfigure (i think) state. You've been Cc:'ed in on the conversation. The package with the error was clamav-base, not clamsmtp. Please pay attention. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ signature.asc Description: Digital signature
Bug#301518: clamsmtp: Plain installation on sarge fails with /var/lib/ucf/cache not existing
On Mon, Mar 28, 2005 at 01:07:22PM -0500, Stephen Gran wrote: To be fair, the CC didn't make it to him right away - it seems it only left my mail queue sometime this morning. He may not have seen the rest of the conversation. My bad. I replied before I had my morning coffee. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ signature.asc Description: Digital signature
Bug#301518: clamsmtp: Plain installation on sarge fails with /var/lib/ucf/cache not existing
On Sat, Mar 26, 2005 at 05:40:32PM +0200, Arturas Slajus wrote: Installing clamsmtp on sarge throws up error as /var/lib/ucf/cache isn't there and there is nobody to create it. That renders package uninstallable. I am unable to reproduce this error. This is very strange, indeed. I cannot seem to find any reference to that directory in the source code for 1.2, nor in the package. Can you run clamsmtpd from the command line with the option '-d 4' and include the output in another email to this bug report? If you're patient, clamsmtp_1.3-1 should migrate to testing shortly. I should have clamsmtp_1.4-1 uploaded by Monday. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ signature.asc Description: Digital signature
Bug#300175: Patch for clamav/clamsmtp
On Mon, Mar 21, 2005 at 11:07:48AM +0100, Samuel Tardieu wrote: This patch allows users in the same group to read the temporary files. This should solve Erwan's problem, and certainly has solved mine: I'll test and apply this patch to the package and upload tonight after work, but it looks sound. I've also added the start/stop routine for clamav-daemon in preinst/postrm. I'll probably upload with a medium or high priority. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ signature.asc Description: Digital signature
Bug#300203: install script don't create clamsmtp user
On Fri, Mar 18, 2005 at 11:57:40AM +0100, Sythos wrote: New user correctly setted in conf file (answered yes during installation), but no clamsmtp user created Could you send me the before and after config file? Could you also tell me which version you upgraded from? I tested both a standard upgrade from sarge as well as an upgrade from a custom installation (different user than clamav), and both turned out fine. I'm curious as to what might have gone wrong with your setup. It's pretty difficult trying to cover all bases. The shell scripts for config and postinst start looking like spaghetti. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ signature.asc Description: Digital signature
Bug#299969: clamsmtp: package description typo(s) and the like
You've got to be kidding me. We're trying to release Sarge and reduce RC bug counts, and you're playing grammar police? I'm not saying I disagree with the a v.s. an as applied to acronyms such as SMTP, but I will not be uploading a new package for such a trivial bug. Expect to see a fix if something else arises, such as a new upstream release or new translations for debconf. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ signature.asc Description: Digital signature
Bug#297645: clamsmtp: does not free file descriptors when outbound connections cannot be established
On Wed, Mar 02, 2005 at 12:44:03AM +, Chris Mason wrote:
There is a file descriptor leak with clamsmtp that means it will run
out of file descriptors after a period of time. By default Linux
systems have a maximum of 1024 FD's per process and clamsmtp does not
free file descriptors when an outbound connection is attempted but
fails.
After a period of time these file descriptors will eventually run out
and the process needs to be restarted as it will not accept any new
connections.
Upsteam has been aware of this problem for the past couple of weeks,
but has not emailed me since I reported this problem to him.
Please find below a patch to fix this issue:
diff -urN /home/masonc/clamsmtp-1.2/common/spio.c
/home/masonc/clamsmtp-1.2-fix/common/spio.c
--- /home/masonc/clamsmtp-1.2/common/spio.c 2004-11-26
21:22:41.0 +
+++ /home/masonc/clamsmtp-1.2-fix/common/spio.c 2005-03-02
00:23:31.0 +
@@ -154,8 +154,10 @@
fcntl(fd, F_SETFD, fcntl(fd, F_GETFD, 0) | FD_CLOEXEC);
-if(connect(fd, SANY_ADDR(*sany), SANY_LEN(*sany)) == -1)
+if(connect(fd, SANY_ADDR(*sany), SANY_LEN(*sany)) == -1) {
+close_raw(fd);
RETURN(-1);
+}
spio_attach(ctx, io, fd, NULL);
OK. I see. The file descriptor itself is not -1, so when
spio_valid(io) is called in cleanup: and the fd is not -1, it is
assumed the connection was made and the descriptor is not closed. It
looks like the spio_t wrapper structure needs more stateful information,
and spio_valid(io) needs to be a little more robust.
Your fix would work, but I see what the author was trying to do. Rather
than calling close_raw(fd) immediately, he may choose to do something
like:
io-connected = connect(fd, ...)
if (io-connected == -1)
RETURN(-1);
But then again, that's putting a lot of effort into a wrapper structure.
*shrug* We'll see. I'll use your patch and see if I can't get him to
talk a bit.
--
Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/
assert(expired(knowledge)); /* core dump */
signature.asc
Description: Digital signature
Bug#287743: [PATCH] Re: Bug#287743 junkfilter: Cannot rebuild lists w/o remounting /usr/share
Santiago Vila wrote: Hmm, what you suggest is that the binary package is modified to include *both* the files to be used and their source code. I don't see the data files used to generate matching regular expressions against subject text, IP addresses, and domain names to be source code. They're data files. And it's clearly indicated in the README file that the Makefile that is distributed with junkfilter is intended to be a replacement for the Perl 'jf' application. Because you consider junkfilter a binary package doesn't mean you shouldn't include utilities necessary to update the database of regex files by the junkfilter RC file. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ signature.asc Description: Digital signature
Bug#287743: acknowledged by developer (Re: Bug#287743: junkfilter: Cannot rebuild lists w/o remounting /usr/share)
Debian Bug Tracking System wrote: Just because the junkfilter package puts the files in /usr/share/junkfilter does not mean they are there to be used directly. Certainly, they have to be *somewhere* in the filesystem, but as it's code more than documentation, they are put in /usr/share to satisfy the FHS. The files are there just so that they may be copied to the home directory of whatever user wants to make use of them, so I'm not to consider this as a real bug. Then I would prompt you to mention this in README.Debian. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ signature.asc Description: Digital signature
Bug#287743: [PATCH] Re: Bug#287743 junkfilter: Cannot rebuild lists w/o remounting /usr/share
Santiago Vila wrote: Hmm, what about Place the junkfilter files wherever you want them. $PMDIR/junkfilter is a likely choice? This is from README.gz. Do you think it's not enough? Should I perhaps remove README.Debian so that people who only read a single file read the original README instead? (This is not a rethorical question. The README.Debian file does not really say anything which is not already said in the upstream README, so removing it is a real possibility here). Sure. I think my original concern was with the sysadmin being able to update rules by running the make all command as indicated in the README file. The original list files are not included in the package, and neither is the Makefile used to regenerate them. The TODO file shows that Greg intended on rewriting jf with a Makefile, which he does include in the source but is not included in the package. In any case, it doesn't sound like either of us are really interested in the package. As it stands, the package is probably fine the way it is. The only changes I'd make would be to include the Makefile and original lists /usr/share/junkfilter. If someone was really interested in the package and wanted to make it sysadmin friendly for site-wide filtering(i.e. it works out of the box), then let that person pick up the mantel of maintainer. In the mean time, here's a simple patch to include the list files and Makefile with the package. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ --- debian/rules.orig 2005-03-09 11:12:02.0 -0600 +++ debian/rules2005-03-09 11:27:39.0 -0600 @@ -18,7 +18,9 @@ rm -rf debian/tmp install -d debian/tmp/DEBIAN $(docdir)/examples cd debian/tmp install -d usr/share/$(package) usr/lib - cp -p jf* junkfilter* debian/tmp/usr/share/junkfilter + cp -p jf* junkfilter* Makefile address bodychk dialup headers \ + ip white debian/tmp/usr/share/junkfilter + cp -pr domain debian/tmp/usr/share/junkfilter # Temporary hack: rm -f debian/tmp/usr/share/junkfilter/junkfilter.four.orig signature.asc Description: Digital signature
Bug#297645: clamsmtp: does not free file descriptors when outbound connections cannot be established
Chris Mason wrote: Please find below a patch to fix this issue: I'll include it in the 1.3-0 upload, once I fix the issues I'm having adding a new system user/group for clamsmtp. ;-) -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ signature.asc Description: Digital signature
Bug#297476: clamsmtp: patch with logcheck rules.
Rafael Jesus Alcantara Perez wrote: I've attached the logcheck rules for ignoring logging data. Did you intend for this to be saved as debian/clamsmtp.logcheck.ignore.server and installed with dh_installlogcheck? -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ signature.asc Description: Digital signature
Bug#285015: python-cheetah: does not seems to be unicode aware
Nicolas Évrard wrote: cheetah is raising UnicodeEncodeError: UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 1: ordinal not in range(128) Have you had a chance to try the new alpha release of Cheetah, 0.9.16a2 [1]_. It looks like they addressed some Unicode problems in 0.9.16a1. There has been a wishlist request for the new version. I'll send an email to the Cheetah developers to see what their recommendations for Debian will be. Here's an excerpt of the the release note [2]_ from the sourceforge site: 0.9.16a1 (Jan 6, 2005) - fixed a unicode bug in Compiler.py [TR] - added new EncodeUnicode filter that Rene Pijlman contributed (I optimized it slightly) and made it the default filter for all templates. [TR] - added test cases for handling unicode with the default filter [TR] permits nesting [JJ] .. [1] http://sourceforge.net/project/showfiles.php?group_id=28961 .. [2] http://sourceforge.net/project/shownotes.php?release_id=294962 -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ signature.asc Description: Digital signature
Bug#294721: BUG#294721: clamsmtp: listeningoutgoing port switched in conf template file
Sythos wrote: in default conf file installed listening port and outgoing port is switched (the doc is right, but inside clamsmtpd.conf it is wrong) Which doc are you talking about? I explicitly listed the differences between the default configuration file and the Debian configuration in /usr/share/doc/clamsmtp/README.Debian. Historically, setups for amavisd and amavisd-new with postfix have used 10025 as the return port to the MTA. # From smtp-amavis back to posfix 127.0.0.1:10025 inet n - n - - smtpd -o content_filter= -o local_recipient_maps= -o relay_recipient_maps= -o cleanup_service_name=scanned -o mynetworks_style=host -o mynetworks=127.0.0.1/32 -o smtpd_restriction_classes= -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject So, rather than make the postfix administrators add yet another smtpd process, I switched the default clamsmtp ports. This may not be the way the software author does things, but it makes it easy for existing Debian postfix/amavisd-new users to experiment with an alternative virus scanner. But then again, all of this is in the README.Debian file... -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ signature.asc Description: Digital signature
Bug#295112: clamsmtp requires newer start-stop-daemon, but can be installed without
Brian Ristuccia wrote: Package: clamsmtp Version: 1.2-3 Severity: serious The init.d script for clamsmtp breaks with start-stop-daemon in dpkg (1.9.21) because it doesn't provide the --group option. It needs to use one of the various dependancy mechanisms to make sure a newer dpkg providing this option gets upgraded on install. Clamsmtp doesn't work unless the init.d script is manually edited or dpkg is manually upgraded. Although, I agree that this is a policy error, the scope of the error only applies to back porting the package. In any case, I added the dependency checking to the control file as suggested. I've been debating whether or not to add a dedicated system user and group for clamsmtp for a number of reasons. Although there is no policy mandating daemons run as their own user and group, doing so might make things a bit more flexible and secure for the daemon. Now that clamsmtp can actually run scripts, I'm not too comfortable having it run as clamav:clamav. A systems administrator may have added the clamav user to priveleged groups for scanning protected filesystems. A poorly written and exploited script run from clamsmtp may now have access to these documents. Granted, it might not be likely such an attack would be probable or even successful, there's no reason to tempt fate. Essentially, if I were to add a clamsmtp:clamsmtp user/group and add clamav to the clamsmtp group so it would have access to the quarantine directory, I wouldn't need to worry about the --group switch to start-stop-daemon. As a result, the package would be easier to back-port to sarge. There is some fragility to this setup, in the face of system administrator customizations. However, we can be reasonably certain that the user and group clamav:clamav will be install. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ signature.asc Description: Digital signature
Bug#295958: test failures when not in /tmp
Chris Walker wrote: Package: cheetah-common Version: 0.9.15-5 If you run cheetah test in a directory other than /tmp, you get 16 failures and 3 errors in /tmp, you get 16 failures, but no errors. Release of 0.9.16a1 indicates that these errors are a result of running test in a directory that isn't writable. - Abort with a helpful error message if user runs 'cheetah test' in a directory without write permission. (Kludge in CheetahWrapper.py; we should probably move the temp files under the system tmp directory.) [MO] Now, the fix in 0.9.16a1 is obviously a helpful error message. So, if the cheetah team isn't going to do more than add an error message, I plan on changing the severity of this bug to minor and tagging it wont-fix. I could possibly back-port the fix, but would you really benefit all that much with an additional error message? -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ signature.asc Description: Digital signature
Bug#295957: Cheetah 0.9.16a2 available
Chris Walker wrote: A new version of cheetah is available (0.9.16a2). Should we be upgrading to alpha quality software as a target for sarge? It does look like 0.9.16a1 fixed quite a few bugs and added a few features, but the fact that the cheetah team released the software as alpha indicates to me that it may not be ready for the stable target of Debian. I could package it and mark it sid-only. *shrug* -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ signature.asc Description: Digital signature
