The /etc/env.d/40vlnx set the wrong ld variable. It set to LD_LIBRARY_PATH, and have to be LDPATH. Reproducible: Always Steps to Reproduce: 1.emerge vlnx Actual Results: Editing the file, correct the problem
I can confirm this 100%. The env.d file is broken. In fact, you don't even need the PATH= (let's keep our PATHs clean). I would like to suggest a makeover for this ebuild. Attached is all my stuff.
Created attachment 33243 [details] vlnx-416e-r1.ebuild
Created attachment 33244 [details] uvscan.conf
Created attachment 33245 [details] uvscan.cron
Created attachment 33246 [details] uvscan.sh
Created attachment 33247 [details] check-updates.sh If you'd like me to mirror this so it can be placed in SRC_URI, let me know.
Created attachment 33248 [details] vlnx-416e-envd
One final thing, I believe check-updates.sh forces us to add: RDEPEND="dev-lang/perl" since it uses perl to massage the version string for virus definition updates.
I keep forgetting to mention... this is now under app-antivirus.
Created attachment 33439 [details] vlnx-432e.ebuild Woah! uvscan went berserk on me today on all my servers, eating up CPU or segfaulting. This prompted me to upgrade to a newer version, which seems to have fixed the problem. Attached are two new files. I added a helpful info line for amavisd users, too.
Created attachment 33440 [details] vlnx-432e-envd
Created attachment 33969 [details] Modified check-updates to use ncftpget instead of lftp lftp hangs on "Resolving Host Address" for me, so I altered the script to use ncftpget instead. Otherwise identical. Use if or as you like.
I have a feeling that I should be using wget so I do not have to worry about another dependency. In any case, I'll worry about that after I get some more feedback.
Do NOT use --fam in uvscan.conf. I just severely messed up my data partitions. I will update the uvscan.conf attachment as soon as I can.
vlnx-432e now in portage; please test :)
the check-updates.sh script is compressed with gz. so, you have to gunzip it in the ebuild to use it! very good work! tkz
Woops! The unpack transparently handles the gunzip, but I had the doins command wrong. Nice find; change is in portage. And I bumped it to -r1 so everyone gets the script.
I see that the cron.daily/uvscan, don't have the path in the uvscan line! I think that you can put the path to the cron.daily doesn't depend on PATH environment variable! (my english is not good) very good work
I think that the readme.txt don't show the version now. So, the check-update.sh file don't work as expected. So, I put another regular expression to a webpage, and everything works well. Can you update the file? ${WGET} "http://vil.nai.com/vil/DATReadme.asp" if [ -f DATReadme.asp ]; then DAT_NEW=`perl -ne 'print $1 if /<td class="tableDataBackground">(\d{4})<\/td>/' DATReadme.asp` else echo "Failed to retreive virus definitions version" rm -rf {$TEMPDIR} exit fi tkz... Wagner Sartori Junior
Wagner, thank you for the contribution. I noticed this issue and I'm working on a fix. In the future, please try not to reopen bugs unless you are certain the same exact bug is still occuring. In this case, this specific bug has almost nothing to do with the original bug. I am closing this bug again. If you would like to open another bug, please do so, but I am working on a fix and should have it available soon.
Ok Wagner, check out the version in CVS now. I bumped the version, switched to the ZIP download (significantly smaller), now use update.ini to check the version, and fixed the path in the cron script.
