There is a bug with assp-1.3.1 to assp-1.3.3.1 where large messages cause the CPU load to run at 100% and take several minutes to send. Assp release a patch but must be installed with a 1.3.3.1 base. I've attached both the 1.3.3.3 patch and new ebuild. Tested on ~x86 and ~amd64. Due to the fact it's a bug, not filing as an enhancement.
Created attachment 130356 [details] assp-1.3.3.3.ebuild
Created attachment 130357 [details] assp-1.3.3.3.patch.tbz2
Any thoughts on http://sourceforge.net/mailarchive/forum.php?thread_name=C00012623339BD4585F7C70EEE07B65D44AE17%40a2.starrag.com&forum_name=assp-user Looks like 1.3.3.3 is crashing for some. Guess pick your poison 100% CPU or crashing :) I will likely still proceed with patching and bumping. But likely so people can pick their poison. Trying to hold back at bitching at upstream about QA. But it's getting there.
Yeah, I see that is a problem. However, portage will pull the newer version of 1.3.3.3-Patch down when a user runs it. Assuming they don't have a cached copy in distfiles. But I agree, the QA on this is horrible. In the mean time, rm /usr/portage/distfiles/ASSP_1.3.3.3-Patch.zip; emerge -av --digest assp is a workaround for upsteam buggy release(s). >:( Of course, lets hope it's finally fixed before the official digest is done. I tested this new version and it works on the email interface. (What crashed before he fixed it)
Following upstream ML I am not happy at all. The newer versions seem to have more and more problems. One user stated the are reverting back to 1.2.x. Glad I left that in tree :) If this keeps up I will have to learn some perl and get in on this. Or something other than just bitch. But leaving it up to Fritz and others of upstream. Is starting to seem like a risky proposition. Destroying a great app I have run without problems for >1111 days. It's made a big difference in my life. Living it without spam in my inbox :) I will likely see about packaging another version or etc. But really don't like what's going on with upstream. Ideally would rather wait till it all calms down, since I am not effected by the 100% cpu issue.
I am seeing the CPU issue now. I am not happy about it. I just reverted back to 1.2.6. I have no clue what to package next or what to do. I am going to make a plea to upstream to get their act together and do another release. Hopefully a stable one :(
Well the 1.3.3.3 patch resolve the CPU bug for me. And the latest version also fixed the crash bug with the email interface. It's been running for two days now without crash or CPU problems. The other thing is that 1.3.x added a lot of new anti-spam features that make a big difference. Such as URI obfuscation blocking (worms/virus/and spam), URI blacklist that block messages with reported "blacklisted URIs", and a few other nice things. While I will continue to use 1.3.3.3 in my overlay, I would recommend bumping portage for others. I still agree that upstream needs to get some good QA work before pushing out releases and patches. Normally I wouldn't recommend being on the "bleeding edge", but you have to revert assp back to 1.2.x to fix the CPU bug.
Well with regard to the security issue. I really can't stabilize a package that is not a official release version from upstream? Maybe I can no clue. I will have to look into that. Beyond that I don't have a huge problem adding 1.3.3.x to the tree :) Short of doing that work, and then another release taking place and having to do it again. Being that I just did 1.3.3.1. Wouldn't be a big deal if I didn't have other packages to deal with. Or if the patch wasn't so freaking huge that I have to tar it up and mirror the sucker. I made a plea to upstream. Hopefully we will see a official release ASAP. Or at least a stance on if 1.2.6 is insecure or not. Either way, one or the other should allow us to move past this. As for the new features, that's all fine and dandy. But who cares if it breaks the older ones or causes functional issues :)
It is, of course, your call. But I did try to do most of the work for you. Ebuild is written, patch was adjusted for 1.3.3.3, then tared and bziped, just needs upload to mirror. From what I've read, Fritz is working on 1.3.4 so he back-ported the fixes to 1.3.3 and the crash bug was from a function that isn't in 1.3.3. I would add that the 1.3.3.3 patch is on source forge so wouldn't say it's not official. But regardless of what happens, I'm set using 1.3.3.3, so it's your call what to do from here.
(In reply to comment #9) > It is, of course, your call. But I did try to do most of the work for you. > Ebuild is written, patch was adjusted for 1.3.3.3, then tared and bziped, just > needs upload to mirror. Sure and I appreciate that. HOWEVER, if I am to commit something. I become 100% responsible for it. Thus I must review it on some level. Which requires time. I have issues with others apps. Some what more important. Like one with Firebird I have to address. Granted some of the stuff that I have done recently like with limewire and etc is kinda moot issue stuff. I kinda enjoy that, so I consider it work being done in my free time :) Vs dealing with assp is not fun for me. > From what I've read, Fritz is working on 1.3.4 so he back-ported the fixes to > 1.3.3 and the crash bug was from a function that isn't in 1.3.3. I would add > that the 1.3.3.3 patch is on source forge so wouldn't say it's not official. It's not really been announced as the current release. Nor site home page updated to reflect it. That's why I emailed upstream about what's up with the next official stable release. > But regardless of what happens, I'm set using 1.3.3.3, so it's your call what > to do from here. I have reverted back to 1.2.6. I have contacted upstream inquiring about the security issue and if 1.2.6 is effected or only 1.3.3. Also asking when the next official release will be so I can package it. Going at it from two directions, both reliant on information or action by upstream. Doing what I can.
Many are still reporting issues with 1.3.3.3 and 100% CPU. Seems mostly on windows due to some perl module, NET:DNS thing needing to be >.61 or etc. But seems others on Linux are still having the same problem. Even with that updated perl module. Fritz and others are blaming it on slow DNS. But me personally fail to see how a slow DNS response is going to make another app max out a CPU in the mean time. That sounds like horrible design regardless of DNS speed. So very curious if anyone else running 1.3.3.3 is seeing any 100% CPU usage on Linux.
I would add that downgrading to 1.3.1 "fixed" the slowness with large attachments. And putting only 1.3.3 back on, 60 seconds later, and it was slow again. So some code has changed in ASSP that effects this issue. May not be sole source but from my testing was in ASSP code. Wish they would make 1.3.3.3 an main release and get it over with.
This is crazy but now there seems to be 100% CPU usage if/when any DNS issues occur. http://sourceforge.net/mailarchive/forum.php?thread_name=1191519931.29056.10.camel%40wlt.obsidian-studios.com&forum_name=assp-user I run my own internal name servers so it's moot. BUT if my main line to the outside world goes down, and/or there is other DNS issues. I don't really want my mail server sitting there at 100% CPU usage till the DNS issues are resolved. I am very concerned with 1.3.x, and at this point will be remaining with 1.2.6 for the foreseeable future. Despite it having a few issues, and 1.3.x having some new features and all.
Ok looks like per comments upstream and etc. I need to see about packaging 1.3.1 again and add that back to tree. Till another release is made. Despite the patch being official, I don't really want to kludge together a release out of 1.3.3.1 and a patch. To create a version that upstream hasn't labeled or released together. Really hoping there is another release sometime soon. But would rather they hold off to ensure any new release is stable, and mostly bug free.
*** Bug 195853 has been marked as a duplicate of this bug. ***
1.3.3.7 was just released. Going to close this bug and open a version bump bug. Mostly as a reminder till I have time to package that version. Hopefully later today, but more than likely sometime tomorrow.
