Bug#561834: (no subject)
I do see now that it DID change content encoding to UTF-8. Maybe it cached the previous main frame page some time. But I can not really explain it in another way. Anyway, it look good now. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561834: vdradmin-am and UTF8
>> So I have now changed LANG = in /var/lib/vdradmin-am/vdradmind.conf to LANG >> = sv_SE and that fixed the nameofday >Ok, I think I see the problem. vdradmin uses an unusual way to determine, if >utf-8 should be used. The charset is read from the gettext translation, and as >there is no Swedish translation (feel free to provide one!), the html-encoding >used is always iso8859-1 Yes, maybe I will translate at a later time. But not everyone want everything in Swedish but still want to have the names handled correctly. With this new version using LANG = sv_SE in vdradmind.conf, it will show up wrongly. But it will now work without the LANG defined so I removed that setting witch is the default. >I did a quick test with sv_SE.UTF-8 and already forwarded the patches >upstream, but it would be nice, if you could test this too and let me know, if >it fixes your problems. Yes, thank you! It fixes the current problems, also the one with the recordings. How about using UTF-8 as standard web content encoding and then translations could change if something else is needed. Naturally iso8859-1 and others would have to be supported for sending correct coding to vdr but I see no big reason to support browsers that do no handle uft8 at this time. I still propose a wishlist to change the default web content-coding to UTF-8 and then allow for translations to change it if needed. ~cat channels.conf | wc -l 6366 With a one antenna and a satellite dish and many channels (not everyone viewable) , not every name and description fits into iso8859-1. I still do see channel-names that still look weird with the black diamond shape with the ? inside. Some of the errors is probably the channelcoding inside vdr but I think it shows the reason for a change. It is now translating everything from UTF8 to iso8859-1 only to show it on web pages and then back into UTF8 for vdr when this is not really needed. I guess this is another request that we should not handle in this bug, but it is related. -- Johan Thelmén -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561834: vdradmin-am and UTF8
>That shouldn't happen there must be another bug hidden somewhere. Please >provide the following information: > >1. The output of the `locale` command >2. cat /var/lib/vdradmin-am/vdradmind.conf | grep LANG >3. cat /etc/default/vdr | grep VDR_ >4. cat /etc/default/locale | egrep 'LC|LANG' >5. cat /etc/environment | egrep 'LC|LANG' tv:~ locale LANG=sv_SE.UTF-8 LC_CTYPE="sv_SE.UTF-8" LC_NUMERIC="sv_SE.UTF-8" LC_TIME="sv_SE.UTF-8" LC_COLLATE="sv_SE.UTF-8" LC_MONETARY="sv_SE.UTF-8" LC_MESSAGES="sv_SE.UTF-8" LC_PAPER="sv_SE.UTF-8" LC_NAME="sv_SE.UTF-8" LC_ADDRESS="sv_SE.UTF-8" LC_TELEPHONE="sv_SE.UTF-8" LC_MEASUREMENT="sv_SE.UTF-8" LC_IDENTIFICATION="sv_SE.UTF-8" LC_ALL= tv:~ cat /var/lib/vdradmin-am/vdradmind.conf | grep LANG LANG = LANGUAGE = English tv:~ cat /etc/default/vdr | grep VDR_ #VDR_LANG=C #VDR_CHARSET_OVERRIDE=ISO-8859-9 tv:~ cat /etc/default/locale | egrep 'LC|LANG' LANG=sv_SE.UTF-8 tv:~ cat /etc/environment | egrep 'LC|LANG' LANG=sv_SE.UTF-8 So I have now changed LANG = in /var/lib/vdradmin-am/vdradmind.conf to LANG = sv_SE and that fixed the nameofday http://87.227.108.179/vdr_dayname.png part. But it still fails the recording part from what I guess it is not converting the charset=ISO-8859-1 back to UTF8 when it receives the input from the browser when recording a program. This one http://87.227.108.179/vdrutf8.jpg it display the program name correct in the recording webpage and then wrong when looking at the webtimer page when it use the input of the browser. -- Johan Thelmén -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561834: vdradmin-am and UTF8
Hi I noticed that utf8 was fixed in 3.6.5-1 and then again broken in 3.6.5-2 after a new patch. Since it refers to this bug I decide to reopen. This time only some parts of UTF8 is broken, all displaing of weekdaynames all over pages that use it, I guess it come from some time display function perl i guess. http://87.227.108.179/vdr_dayname.png Should display Söndag instead of söndag. I notice webpages is now sent with charset=ISO-8859-1. The bad part is that it affect the recorded name in vdr. It probably forget to convert back to UTF8 when it communicates back to vdr. Like this http://87.227.108.179/vdrutf8.jpg The correct name is marked Skål when recording directly from vdr and if I select and recording the same program from vdradmin-am it look like the top entry in the list witch is not correct. This was no problem with the previous patch when it sent the webpages in utf8 encoding since then also the response to vdradmin-am and then back to vdr was also in utf8. It look like my vdr setting should be ok. telnet localhost 2001 220 tv SVDRP VideoDiskRecorder 1.6.0-2; Sun Feb 14 11:07:19 2010; UTF-8 I hope we can fix this again. -- Johan Thelmén -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100214.22770@home.se
Bug#496254: (no subject)
Short testcase..
perl -e 'use Sys::Syslog qw(:DEFAULT
setlogsock);setlogsock('unix');openlog("info","cons,pid,ndelay","user");syslog("info","Test
bad");closelog();'
logger "Test OK";tail -n3 /var/log/syslog|cat -A
And show this for me:
info[27999]: Test bad $
logger: Test OK$
Notice the space after bad that is unwanted.
--
Johan Thelmén
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#496254: Syslog.pm adds newline and later EOL whitespace to spamassassin /var/log/syslog messages
retitle 496254 perl: Syslog.pm adds newline and later EOL whitespace to spamassassin /var/log/syslog messages reassign 496254 perl 5.8.8-7etch3 tags 496254 + patch thanks Hello This is also in lenny perl 5.10.0-19 A somewhat related bug about NULLs is #356700 I can not see that the call syslog($level, "%s", $msg); in /usr/share/perl5/Mail/SpamAssassin/Logger/Syslog.pm is the problem here. This also messes up logcheck for spamassassin that will not match correctly with added EOL whitespace in syslog. This is the second mail, the first have not yet been processed but it was received yesterday by the Debian server. I'l retry from a different server. 2009-03-21 23:44:25 1Ll9vV-0006KY-2x <= j...@home.se H=(tpjohthe.localnet) [10.1.4.16] P=esmtpsa X=TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32 DN="" A=plain_server:johan S=2124 id=200903212344.27368@home.se T="perl: Syslog.pm adds newline and later EOL whitespace to spamassassin /var/log/syslog messages" 2009-03-21 23:44:28 1Ll9vV-0006KY-2x => 496...@bugs.debian.org R=dnslookup T=remote_smtp H=rietz.debian.org [140.211.166.43] 2009-03-21 23:44:28 1Ll9vV-0006KY-2x -> cont...@bugs.debian.org R=dnslookup T=remote_smtp H=rietz.debian.org [140.211.166.43] 2009-03-21 23:44:28 1Ll9vV-0006KY-2x Completed This make the local /var/log/syslog work as expected by commenting out the command that add the newline in the sprintf mask, later converted to space after the message. It will still add another newline when sending to a remote host. I will try to find that one also. Another way to fix this would be to filter the EOL whitespace at some later stage. Could also be a ksyslogd bug that it should strip EOL whitespace. But I think the system should not alter log messages too much if not really needed. --- /usr/lib/perl/5.10.0/Sys/Syslog.pm.org 2009-03-21 22:01:52.0 +0100 +++ /usr/lib/perl/5.10.0/Sys/Syslog.pm 2009-03-21 21:38:00.0 +0100 @@ -330,7 +330,7 @@ $mask =~ s/(?
Bug#491860: pngnq VERSION problem
Package: pngnq
Version: 0.5-2
Tags: patch
Should say on sid, testing, x86 and amd64
pngnq -V
pngnq 0.5
Compiled with libpng 1.2.27; using libpng 1.2.27.
Compiled with zlib 1.2.3.3; using zlib 1.2.3.3.
Is saying on x86 sid
pngnq -V
pngnq (null)
Compiled with libpng 1.2.15beta5; using libpng 1.2.27.
Compiled with zlib 1.2.3.3; using zlib 1.2.3.3.
Is saying on amd64 testing
pngnq -V
Segmentation fault
Seems to work with this fix in debian/rules
-CFLAGS += -D VERSION=\"0.5\" -g ${shell libpng-config --cflags}
+CFLAGS += -D VERSION=\\\"0.5\\\" -g ${shell libpng-config --cflags}
--
Johan Thelmén
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#462333: Please include qvfb
Package: qt4-dev-tools Version: 4.3.3-2 Severity: wishlist Please include qvfb configure option -qvfb -- TIA Johan Thelmén Falun Sweden
Bug#458783: (no subject)
Me too. But found no 2.0.0.9-1 for i386 so using 2.0.0.6-1 instead. -- Johan Thelmén Sweden Falun
Bug#389931: Working in 2.6.18.2
Tags: fixed-upstream thank you I just downloaded and tried 2.6.18.2 with same .config and make-kpkg. Seems to work fine. -- TIA Johan Thelmén Sweden Falun
Bug#385450: SpamAssassin 3.1.7
retitle 385450 Package SpamAssassin 3.1.7 # Waiting ... thank you -- TIA Johan Thelmén Sweden Falun
Bug#389931: Me too
severity 389931 grave thanks Makes the package in question unusable to me and others > 2.6.18 gives a kernel panic if 'apci=off' is specified as a boot parameter. > The issue does not occur with 2.6.17 or earlier. Here it panics without any special option or if try acpi=off or acpi=on. That is every time. Also no problem with erlier kernels. Lets see if I can type this skipping some leading 0 and reserving for typos. CR: 98 CR3: 201000 CR4: 6e0 Process swapper (pid: 1, threadinfo 810037a84000, task 810037ada770) Stack: 282 8033abd1 c2052000 98025e1ee 804259a0 810037f8f800 80425bf0 8031683d 810037f9 09ff80318042 Call Trace: [] acpi_hw_register_read+0x6b/0x1aa [] quirq_via_abnormal_poweroff+0x15/0x40 [] pci_fixup_device+0x7d/0x8b [] init+0x13e/0x30b [] child_rip+0xa/0x12 [] vgacon_cursor+0x0/0x19b [] __down+0x72/0x0100 [] _etext+0x0/0x155ab4 [] init+0x0/0x30b [] child_rip+0x0/0x12 Code: 48 8b 7a 04 48 85 ff 74 47 c7 06 00 00 00 00 8a 02 84 c0 74 RIP [] acpi_hw_low_level_read+0xb/0x60 RSP CR2: 98 <0> Kernel panic .. This is on Microstar K8T Neo2-F v2.0 bios AwardBIOS W7094WMS V3.0 071405 with a AMD64 X2 3800+ CPU Now why did I not think of taking a picture.. before I wrote this. -- TIA Johan Thelmén Sweden Falun
Bug#387410: bluez-utils: fails on upgrade
Marc F. Clemente wrote: > Upon further investigation, I think that /dev/MAKEDEV is SUPPOSED to be > there! Please look at the thread for bug 387995. Run the following > command to put the symlink back in /dev/ > > apt-get --reinstall install makedev > > Marc Yes, If makedev is installed. If I remove makedev dpkg --purge makedev it is not there. Again bluez-utils is depending on udev OR makedev. Eddy Petrişor can I close this as a duplicate bug? I don't think we need four bugs for the same issue. My proposed patch is: if [ -x "$(command -v MAKEDEV)" ]; then echo "Creating device nodes ..." cd /dev; MAKEDEV bluetooth fi Thanks to Martin F. Krafft for patch above also fixing similar problem in fuse-utils #385696. Also policy say it is bad to depend a full path to binary and this patch will obey and use MAKEDEV in the path. -- Johan Thelmén Sweden Falun
Bug#387410: bluez-utils: fails on upgrade
Just a note to Eddy Petrişor. That patch will not work when there is no makedev installed. Instead see the patch in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387193 -- Johan Thelmén Sweden Falun
Bug#387193: ./MAKEDEV: No such file or directory
Package: bluez-utils Version: 3.1-4+b1 Severity: serious Tags: patch Depends: libbluetooth2 (>= 3.0), libc6 (>= 2.3.6-6), libdbus-1-3, libdbus-glib-1-2 (>= 0.71), libglib2.0-0 (>= 2.10.0), libusb-0.1-4 (>= 2:0.1.12), sysvinit (>= 2.80- sysvinit (>= 2.80-1), modutils | module-init-tools, makedev (<< 3.3.8.2-0) | udev, lsb-base (>= 3.0-3), dbus I'm using udev not makedev. bluez-utils is using makedev in setup without depending on it. Setting up bluez-utils (3.1-4+b1) ... Creating device nodes ... /var/lib/dpkg/info/bluez-utils.postinst: line 38: ./MAKEDEV: No such file or directory dpkg: error processing bluez-utils (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: bluez-utils E: Sub-process /usr/bin/dpkg returned an error code (1) Using this instead should fix it. if [ -x "$(command -v MAKEDEV)" ]; then echo "creating fuse device node..." cd /dev; MAKEDEV fuse fi Thanks to Martin F. Krafft for patch above and also fixing same error in fuse-utils #385696. -- TIA Johan Thelmén Sweden Falun
Bug#343988: Any update on udev?
Need a patch? -- TIA Johan Thelmén Sweden Falun
Bug#385696: Depends or not.
severity 385696 serious thanks < Putting makdev as a depencency is enough to ensure that this symlink is in place. Yes it would, but you do not depend on it.. It is makedev OR udev see? Depends: libc6 (>= 2.3.6-6), sed (>= 4), ucf, adduser, makedev (>= 2.3.1-80) | udev I had to ask anotherone from #debian-bugs just to make sure.. [08:05] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=385696 Is it a rcbug or not? Not depending on makedev and then use it in post-installation script and fail to configure? Use a path prepended and other packages depending on this package. [08:16] doing weird stuff to your configuration that breaks other stuff isn't rc. [08:17] rm -rf /bin/sh ; reportbug initscripts ; severity critical ; do not work without a /bin/sh symlink [08:31] pusling: It will still fail if I do not change my configuration.. It is not depending on makedev and will fail without any of my configuration. If I remove makedev and try to install I will get the same error without change to my configuration.. [08:31] ah. [08:31] then yes. So if it survive configuration without having makedev it is ok. Just by adding || true -- TIA Johan Thelmén Sweden Falun
Bug#385696: Depend..
Well fuse-utils do not depend on makedev and should not I think. I use udev instead. But why depend on that link? Why not use cd /dev ; MAKEDEV fuse 2>/dev/null || true or this for no output cd /dev ; MAKEDEV fuse 2>/dev/null >/dev/null || true Then if there is no MAKEDEV in path it is ok anyway. I'm not starting makedev on startup, I do not want that link. -- Johan Thelmén Sweden Falun
Bug#385696: ./MAKEDEV: No such file or directory
Package: fuse-utils Version: 2.5.3-4 Severity: serious Tags: patch Makes the package in question unusable or mostly so Policy 6.1 Programs called from maintainer scripts should not normally have a path prepended to them. Setting up fuse-utils (2.5.3-4) ... creating fuse device... /var/lib/dpkg/info/fuse-utils.postinst: line 9: ./MAKEDEV: No such file or directory dpkg: error processing fuse-utils (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: fuse-utils E: Sub-process /usr/bin/dpkg returned an error code (1) x:/dev# ./MAKEDEV fuse bash: ./MAKEDEV: No such file or directory x:/dev# MAKEDEV fuse udev active, devices will be created in /dev/.static/dev/ And, or add true so it do not abort on fail. || true -- TIA Johan Thelmén Sweden Falun
Bug#362281: Stop now
Tzafrir Cohen wrote: > On Mon, May 29, 2006 at 05:44:16PM +0200, Johan Thelmén wrote: >> >> $REALDAEMON is stripping the ' so it only get the command stop >> >> Tried to replace $CLIARGS in safe_asterisk with $* but then it exited >> with code 1 and restarted and restarted.. >> I probably missed something. >> >> /etc/init.d/asterisk >> stop) >> echo -n "Stopping $DESC: " >> # if [ "$RUNASTSAFE" = "yes" ];then >> # # hopefully this will work. Untested >> # $REALDAEMON -rx 'stop now' > /dev/null || true >> # else >> # Try gracefully. >> # this may hang in some cases. Specifically, when the >> # asterisk processes is stopped. No bother to worry about >> # cleanup: it will either fail or die when asterisk dies. >> ( $DAEMON -rx 'stop now' > /dev/null 2>&1 & ) & >> # fi > > Could you please instead try applying the attached patch to safe_asterisk? > (Basically: replace CLIARGS with a plain "$@") You know when using the $@ in a function, then it is not the arguments from the program we get.. But we can provide the argument from the program to the function as argument. run_asterisk "$@" & + run_asterisk -rx 'stop now' + : + '[' tty9 '!=' '' ']' + cd /tmp + stty sane + /usr/sbin/asterisk -rx 'stop now' -vvvg -c + echo -n asterisk asterisk+ '[' yes = yes ']' + start-stop-daemon --quiet --oknodo --stop --exec /usr/sbin/safe_asterisk + start-stop-daemon --stop --quiet --oknodo --retry=0/2/TERM/2/KILL/5 --exec /usr/sbin/safe_asterisk + echo . . + exit 0 fs1-blg:/etc/init.d# + EXITSTATUS=0 + echo 'Asterisk ended with exit status 0' Asterisk ended with exit status 0 + '[' 0 = 0 ']' + echo 'Asterisk shutdown normally.' Asterisk shutdown normally. + exit 0 It gets shutdown but.. + EXITSTATUS=141 The shutdown command.. in a loop. So why make it so hard and not use the same shutdown as non safe? See my /etc/init.d/asterisk above Is there a problem using $DAEMON instead of $REALDAEMON? Remember $REALDAEMON is not the realdaemon asterisk but the the safe_wrapper for some strange reason. Also please try patches before posting and submitting.. -- Johan Thelmén Sweden Falun
Bug#362281: Stop now
$REALDAEMON is stripping the ' so it only get the command stop Tried to replace $CLIARGS in safe_asterisk with $* but then it exited with code 1 and restarted and restarted.. I probably missed something. /etc/init.d/asterisk stop) echo -n "Stopping $DESC: " # if [ "$RUNASTSAFE" = "yes" ];then # # hopefully this will work. Untested # $REALDAEMON -rx 'stop now' > /dev/null || true # else # Try gracefully. # this may hang in some cases. Specifically, when the asterisk # processes is stopped. No bother to worry about cleanup: # it will either fail or die when asterisk dies. ( $DAEMON -rx 'stop now' > /dev/null 2>&1 & ) & # fi -- Johan Thelmén Sweden Falun
Bug#360843: Not so fast
I don't think it is fixed in 2.25-2.. amd:/tmp# dpkg -i manpages-dev_2.25-2_all.deb (Reading database ... 296724 files and directories currently installed.) Preparing to replace manpages-dev 2.23-1 (using manpages-dev_2.25-2_all.deb) ... Unpacking replacement manpages-dev ... dpkg: error processing manpages-dev_2.25-2_all.deb (--install): trying to overwrite `/usr/share/man/man2/create_module.2.gz', which is also in package modutils dpkg-deb: subprocess paste killed by signal (Broken pipe) Errors were encountered while processing: manpages-dev_2.25-2_all.deb amd:/tmp# dpkg -c manpages-dev_2.25-2_all.deb | grep create_module -rw-r--r-- root/root 900 2006-04-03 21:23:47 ./usr/share/man/man2/create_module.2.gz -- TIA Johan Thelmén Sweden Falun
Bug#360159: clamscan / clamd takes excessive CPU then segfaults
fredag 31 mars 2006 01:35 skrev David Luyer: > > Package: clamav > Version: 0.88-4 > > An email with a particular attached Excel spreadsheet causes > clamscan / clamd to take a long time to process, and eventually > segfault (eventually causing all clamd processes to fail on a > machine). > > Backtrace: > > #0 0x4002a784 in cli_bitset_test () from /usr/lib/libclamav.so.1 > #1 0x40042d63 in textToFileblob () from /usr/lib/libclamav.so.1 [cut] Little useful report. Problem in cli_bitset_test or textToFileblob. > As this is a customer email I cannot provide the exact email contents, > however I can provide more details from the core dump or test any > potential fixed version. It think it would be more helpful if you made a debug nonstripped version of clamav .deb package so you can send a new better backtrace to Stephen and only to Stephen since many more is scanning mails with clamav and don't want it to crash. file /usr/bin/clamscan /usr/bin/clamscan: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), for GNU/Linux 2.2.0, stripped To build nonstripped version, it is something like this. Make sure you have a deb-src line in /etc/apt/sources.list like this if using sid.. deb http://ftp.debian.org/debian sid main contrib non-free deb-src http://ftp.debian.org/debian sid main contrib non-free apt-get build-dep clamav apt-get source clamav cd clamav-0.88/ export DEB_BUILD_OPTIONS=nostrip dpkg-buildpackage -b -us -uc cd .. dpkg -i libclamav1_0.88-4_i386.deb clamav_0.88-4_i386.deb clamav-base_0.88-4_all.deb file /usr/bin/clamscan /usr/bin/clamscan: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), for GNU/Linux 2.2.0, not stripped Then try again. Hope this helps. It would be better to try the cvs version, but I must go now. -- Johan Thelmén Sweden Falun
Bug#304363: Needs slight ajustment
I get this.. in 3.1.0a-2
Nov 12 02:23:24 ta2 spamd[28371]: spamd: got connection over
/var/run/spamassassin/spamassassin.socket
Nov 12 02:23:24 ta1 spamd[29074]: spamd: got connection over
/var/run/spamassassin/spamassassin.socket
Should probably add ( spamd:)?
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ spamd\[[0-9]+\]:( spamd:)? got connection
over
--
TIA Johan Thelmén
Sweden Falun
Bug#328660: Urgency low..
Changes: clamav (0.87-1) unstable; urgency=low * New upstream version - Fixes CAN-2005-2920 and CAN-2005-2919 (closes: #328660) I can not find any policy about it but I think it should be urgency high or atleast medium. This for building faster (if used) and faster moving in to testing. Two weeks for a remote security fix is not that good when the fix is known. Please think about it next time. -- Johan Thelmén Sweden Falun
Bug#321725: clamav: please provide command or option to clamdscan to reload databases
söndagen den 7 augusti 2005 10.01 skrev Marc Haber: > Package: clamav > Severity: wishlist > > Hi, > > please give clamdscan an option to signal a running clamd to reload > the databases. Alternatively, please include a clamdreload binary > which does this. Like this? killall -USR2 clamd -- Johan Thelmén Exim & clamav user Falun Sweden
Bug#295137: Working icons now
Someone forgot to close this bug? Then again DDEserver is now not working but that is another problem and bug. -- Johan Thelmén Sweden Borlänge
Bug#297915: exim4: Mail duplicated
torsdagen den 3 mars 2005 15.27 skrev John Goerzen:
> Package: exim4
> Version: 4.34-10
> Severity: normal
>
> I am using the exiscan support for spamassassin.
>
> I am having trouble with exim4 delivering duplicated copies of messages.
> Spamassassin is giving me trouble, using 40+ minutes of CPU time to
> process some messages, but I would think that exim4 should be more
> resilient in the face of this.
>
> It seems that remote hosts for some reason believe the message did not
> get delivered, even though it did, and try repeatedly to re-send it.
If processing a message take more then one minute you should find out why
spamassassin is taking so long. The server sending the message to exim have
to wait until spamassassin is complete before it send the final OK accepted
for delivery from exim. This time have to less then ten minutes set by the
SMTP RFC standard. If it take longer the sending server think there is
something wrong and will dissconnect and retry later without exim knowing.
That way exim will deliver the message and the other server try again.
In reality some people is not even following the RFC standard and I have seen
this same problem on some messages that only take over 90seconds to scan.
I changed to a faster server and the problem went away.
Maybe you are not limiting size of mails you are scanning with spamassassin.
I have this before the spamcheck that is the last check.
# Do not spamcheck mail over 150K when overloaded
accept
condition = ${if >{$message_size}{150k}{1}{0}}
condition = ${if >{$load_average}{900}{1}{0}}
# Do not spamcheck mail over 2M when we have other work to do
accept
condition = ${if >{$message_size}{2m}{1}{0}}
condition = ${if >{$load_average}{70}{1}{0}}
Good luck.
--
Johan Thelmen
Falun Sweden
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#295658: asterisk 1.0.5-2 using chan_skinny die without this patch
Package: asterisk Version: 1.0.5-2 Severity: important Tags: patch http://bugs.digium.com/bug_view_page.php?bug_id=0003496 -- Johan Thelmén
Bug#295137: Me too..
Unusable version. -- Johan Thelmén Falun Sweden
Bug#292190: Works for when using CONFIG_BLK_DEV_AMD74XX=y
CONFIG_BLK_DEV_AMD74XX=y -- Mvh Johan Thelmén
Bug#291689: Me too.. Missing OSD in kernel-image-2.6.10-1-k7
Just installed kernel-image-2.6.10-1-k7 and got no OSD Jan 23 06:01:46 localhost vdr[4929]: ERROR: illegal OSD device handle (-1)! Jan 23 06:01:46 localhost vdr[4929]: ERROR: cOsd::SetAreas returned 6 grep -B1 OSD /boot/config-2.6.10-1-k7 CONFIG_DVB_AV7110=m # CONFIG_DVB_AV7110_OSD is not set -- TIA Johan Thelmén Sweden Falun
