AVG Anti Virus is a popular, free, program that now has a linux version. AVG comes with both gui and command line software. This version is the free, noncommercial use product. This ebuild adds a new user/group pair: avg:avg. Users who belong to the avg group can update the virus database. Others, can just run the scanner. Maintainers may wish to examine the way I handle the postrm routine. Basically, since AVG updates its software directories, unmerge does not clean out everything. So, I manually test to see if a new emerge is an update, replacement, or an unmerge, and remove files if and unmerge. I also manually remove /etc files since, if the program is gone, they are not needed. The daemon included here requires dazuko in order to run, however, I did not list it as a depend since it's optional. I do test for it being installed and show messages as to what to do. I had to modify their daemon startup script to make it more gentoo-friendly. avgd should be in the files directory. There is a cron job script which is commented, but will download updates every day if activated. Finally, there is a rather large PDF manual which will only be downloaded and installed if USE="doc" is set. There is a message about this too. Looking forward to comments on the way I structured this ebuild. PS. there are several commercial versions of this, but I have not examined those products.
Created attachment 81851 [details] avgfree-7.1.23.ebuild
Created attachment 81852 [details] files/avgd (init.d daemon script)
Created attachment 81853 [details] avgupdate.cron (daily virus update)
Created attachment 81865 [details] avgfree-7.1.23.ebuild Neglected to install .desktop and pixmap file.
Created attachment 81930 [details] files/avgd (init.d daemon script) Unfortunately, for some reason, the PID placed in the daemon's pid file is incorrect. It's one less than the proper one. Therefore I changed the stop routine to kill the daemon based on its --exec name, not --pidfile.
My bad luck. Today a new version. Replacing .23 ebuild. Also reworked some logic.
Created attachment 81933 [details] avgfree-7.1.24.ebuild
Hello Peter, I'm not sure if I responded to your mail, because I'm kind of in flux nowadays. I'm looking for a flat to live in, while staying at my friend's house, plus I've had graveyard shifts at work all week. I'll definitely be looking to add this package to portage, once I'm a bit settled, though. On a quick glance, the ebuild looks good. However, you have forgotten to include rpm2targz and sed in DEPEND (not RDEPEND - they're used during the build by your ebuild. I also believe that suggesting users to change USE variable on command line before emerge is a bad thing, try to suggest modifying package.use instead. Thank you for your effort so far!
I'll implement your suggestions. I had never seem a "modify package.use" message. but had seen many "if you want this, do USE="blah" emerge..." But, if package.use is the proper way, I'll grep the ebuilds and see what others have done. ITMT, I wrote to upstream to mention that their daemon sets the wrong PID in their PID file, so start-stop-daemon can't kill the daemon with its PID! I see what's happening though. avgscan runs and gets a PID (1000 call it) avgscan forks a file watcher process (1001) avgscan forks a second watcher process (1002) avgscan (1000) ends leaving 1001 and 1002 avgscan sets the PID file with the calling program's PID (1000). Even their own directions won't work. kill -TERM `cat pidfile` The workaround using the --exec seems to work though.
Created attachment 81947 [details] avgfree-7.1.24.ebuild Several changes as recommended by Andrej. 1) add DEPEND for rpm2targz and sed 2) reworked postinst routine to suggest user use package.use for doc instead of suggesting USE=doc emerge... 3) tried to make info messages more clear esp. wrt Dazuko and why the init.d file is there even if it can't be used. 4) moved DAZUKO test to postinst function and made var local to that function. 5) add quotes to [ -z "${DAZUKO}" ] test since result had spaces and this caused an error. 6) made registration silent with &>/dev/null 7) added lines for user to check the man pages and documentation. Ebuild may still be too heavy on info messages, and it's a little more complex than I like -- esp for an ebuild with no compiling going on. Feel free to trim fat from it if you like.
Created attachment 82008 [details] avgfree-7.1.24.ebuild Copy PDF manual to /usr/share/${PF}/manual instead of /usr/share/${PN}.
Created attachment 82022 [details] avgfree-7.1.24.ebuild don't shoot me. Yet another enhancement. Use enewgroup and enewuser functions from eutils.eclass.
You can use conditional "doc? ( http://foo )" syntax for SRC_URI, similar to *DEPEND atoms. Adding to SRC_URI the way your ebuild does is not a good idea, since it will break certain ebuild utilities. Look at nvidia-kernel ebuild for an example of a conditional SRC_URI atom. Ok, after merging the ebuild, I get this errormessage: ticho@hiker ~ $ avgscan avgscan: error while loading shared libraries: libstdc++-libc6.2-2.so.3: cannot open shared object file: No such file or directory I have libstdc++-v3 installed.
That's odd. peter@mars ~ $ ldd /usr/bin/avgscan /usr/lib/libtrash.so (0xb7fa2000) linux-gate.so.1 => (0xffffe000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0xb7f6c000) libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0xb7f18000) libm.so.6 => /lib/libm.so.6 (0xb7ef5000) libc.so.6 => /lib/libc.so.6 (0xb7ddd000) libdl.so.2 => /lib/libdl.so.2 (0xb7dd9000) /lib/ld-linux.so.2 (0xb7fa8000) peter@mars ~ $ avgscan AVG7 Anti-Virus command line scanner Copyright (c) 2006 GRISOFT, s.r.o. Program version 7.1.24, engine 718 Virus Database: Version 268.2.5/284 2006-03-17 License type is FREE. I know that libstdc++ get's messed up after some gcc upgrades (esp 3.3-3.4). I too have sys-libs/libstdc++-v3 3.3.4 installed. Broken library link? I'll look into fixing the SRC_URI with the doc. I think I tried it before but got an error. I'll be away next week, but will review next weekend or sometime soon afterwards. Thanks again for your help and testing.
Created attachment 82527 [details] avgfree-7.1.24.ebuild Changes SRC_URI handling so that doc? (...) is used.
Created attachment 82535 [details] files/avgd (init.d daemon script) small change. did not remove run pid file. name corrected.
Are we going to move ahead with this? Or should I just close the bug? Thx
No, please leave the bug open, I appreciate your work, and plan to add it to Portage eventually. It's just that currently, I have quite busy schedule, and can barely keep up with gentoo bug fixing, so adding of new packages has to wait. Sorry about that. Unless, of course, someone else from antivirus herd steps up and takes care of this package. I have no problem with that.
Hm, we have another problem here: ticho@thelair ~ $ ldd `which avgscan` linux-gate.so.1 => (0xffffe000) libexpat.so.0 => not found libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0xb7ee1000) libm.so.6 => /lib/libm.so.6 (0xb7ebe000) libc.so.6 => /lib/libc.so.6 (0xb7daa000) /lib/ld-linux.so.2 (0xb7f4a000) dev-libs/expat versions currently in portage only provide libexpat.so.1, unfortunately.
Actually, scratch that - expat-1.95.8 still provides libexpat.so.0. But still, we're going to have to add <dev-libs/expat-2 to RDEPEND.
peter@mars ~ $ sudo equery b /usr/lib/libexpat.so.0 [ Searching for file(s) /usr/lib/libexpat.so.0 in *... ] dev-libs/expat-1.95.8 (/usr/lib/libexpat.so.0 -> libexpat.so.0.5.0) peter@mars ~ $ ldd /usr/bin/avgscan /usr/lib/libtrash.so (0xb7fa6000) linux-gate.so.1 => (0xffffe000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0xb7f6f000) libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0xb7f1b000) expat-1.95.8 is marked stable for x86. Are you running ~expat? If so, maybe I have to put a Depend on that version? Let me know how you want to proceed or what is wrong.
(In reply to comment #13) > You can use conditional "doc? ( http://foo )" syntax for SRC_URI, similar to > *DEPEND atoms. Adding to SRC_URI the way your ebuild does is not a good idea, > since it will break certain ebuild utilities. Look at nvidia-kernel ebuild for > an example of a conditional SRC_URI atom. > > Ok, after merging the ebuild, I get this errormessage: > > ticho@hiker ~ $ avgscan > avgscan: error while loading shared libraries: libstdc++-libc6.2-2.so.3: cannot > open shared object file: No such file or directory > > I have libstdc++-v3 installed. > Ok, figured this one out: ticho@thelair ~ $ equery b /usr/lib/libstdc++-libc6.2-2.so.3 [ Searching for file(s) /usr/lib/libstdc++-libc6.2-2.so.3 in *... ] sys-libs/lib-compat-1.4 (/usr/lib/libstdc++-libc6.2-2.so.3 -> libstdc++-3-libc6.2-2-2.10.0.so) We'll need to add sys-libs/lib-compat to RDEPEND as well.
(In reply to comment #21) > peter@mars ~ $ sudo equery b /usr/lib/libexpat.so.0 > [ Searching for file(s) /usr/lib/libexpat.so.0 in *... ] > dev-libs/expat-1.95.8 (/usr/lib/libexpat.so.0 -> libexpat.so.0.5.0) > > peter@mars ~ $ ldd /usr/bin/avgscan > /usr/lib/libtrash.so (0xb7fa6000) > linux-gate.so.1 => (0xffffe000) > libexpat.so.0 => /usr/lib/libexpat.so.0 (0xb7f6f000) > libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 > (0xb7f1b000) > > expat-1.95.8 is marked stable for x86. Are you running ~expat? If so, maybe I > have to put a Depend on that version? > > Let me know how you want to proceed or what is wrong. > Yes, I'm running complete ~x86 on one of my dev boxes. I think best course of action will be to restrict depend atom to <dev-libs/expat-2, and change that with eventual future versions of avgfree, which will link against newer libetpan. That probably won't happen soon, so this might be a problem in the future, if dev-libs/expat-2 gets marked stable.
Created attachment 86026 [details] avgfree-7.1.24.ebuild Update includes new RDEPEND to protect against expat-2 and include lib-compat as suggested by ticho. This would cause failures on dev platforms. Not sure if expat is slotted though and if forcing a downgrade could cause a problem?
No, expat is not (and can not be made) slotted. What we'll need to do is contact upstream and ask them to provide a new binary. I'll try to get latest ebuild to portage tomorrow, or the day after, but it will be unusable after expat-2 gets marked stable.
Honestly. I would not bother with portage. There are other AV products out there, and this ebuild is here for people who want/need it. The Windows product is superior, and I think they just did Linux as an afterthought. Sorry to have made so much trouble for you. I'll write upstream if you want and nag them about expat.
Yes, the Linux version is an afterthought (who needs a desktop AV scanner for *nix?), but it's still nice to have. Why did you open the bug if you don't want this in portage? :)
Why? Actually, I thought it would be a good addition. But NOT at the cost of these types of hassles. You exposed some poor development choices by the grisoft people. And, if expat-2 goes stable, then we open a big new can of worms trying to keep this thing running. That's why I suggested tabling the idea for the time being rather than release it only to have to yank it because of expat. Don;'t get me wrong. Feel free to update the tree with it. I just don't want to pollute the environment with a bad ebuild or one which will become obsolete in the near future.
You're probably right. If you could find time to point upstream to this bug, it would be nice. There's also another issue - when trying to run avggui as a regular user, it still wants to write to /opt. As if upstream designed it to be run as root. Errors start with: ticho@thelair ~ $ avggui avggui: /opt/grisoft/avggui/prog/sysinfo.py:109: ERROR: opening file: [Errno 2] No such file or directory: '/opt/grisoft/avggui/config/userinfo.cfg' avggui: /opt/grisoft/avggui/prog/messagebox.py:25: WARNING: And more appear f.e. when trying the online update.
Changing status since there will be problems with libexpat-2 when it goes stable. I wrote upstream however it's difficult since tech support requires a serial number which I don't have. I wrote to sales and asked them to forward the message: I package AVG for the Gentoo distribution. Your program will become unusable on Gentoo soon as the libexpat-2 is going stable soon. You will need to update your installer and dependencies list so that libexpat version 1 is no longer used. Or, like VMWare, package your own version of libexpat to avoid any problems. (that would be the easiest solution, IMHO) peter@mars ~ $ ldd `which avgscan` /usr/lib/libtrash.so (0xb7f72000) linux-gate.so.1 => (0xffffe000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0xb7f3b000) libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0xb7ee7000) libm.so.6 => /lib/libm.so.6 (0xb7ec4000) libc.so.6 => /lib/libc.so.6 (0xb7da8000) libdl.so.2 => /lib/libdl.so.2 (0xb7da4000) /lib/ld-linux.so.2 (0xb7f78000) expat-2 will have a new library, libexpat.so.1. We are holding off on porting your package until this is addressed. We'll see when or if they update it. ITMT, users can use this until libexpat 2 goes stable. Then, there will be breakage.
*** Bug 133965 has been marked as a duplicate of this bug. ***
*** Bug 144836 has been marked as a duplicate of this bug. ***
I believe the issue has been fixed in the current 7.5.51 version. Here is the output: ldd `which avgscan` linux-gate.so.1 => (0xffffe000) libavgutil.so.1 => /opt/grisoft/avg7/lib/libavgutil.so.1 (0xb7e61000) libdl.so.2 => /lib/libdl.so.2 (0xb7e48000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7e31000) libresolv.so.2 => /lib/libresolv.so.2 (0xb7e1f000) libstdc++.so.6 => /opt/grisoft/lib/libstdc++.so.6 (0xb7d53000) libm.so.6 => /lib/libm.so.6 (0xb7d2c000) libgcc_s.so.1 => /opt/grisoft/lib/libgcc_s.so.1 (0xb7d24000) libc.so.6 => /lib/libc.so.6 (0xb7bf4000) /lib/ld-linux.so.2 (0xb7f0a000) I managed to run it. Is it the right time to reopen the bug?
Created attachment 147674 [details] avgree-7.5.51 ebuild An updated ebuild with few fixes.
plz move these lines to the beginning of pkg_postinst() (as portage suggested when I tried to emerge) # compile python modules python_mod_optimize ${D}/opt/grisoft/avggui/prog I also needed to change the SRC_URI as the files seem to have been moved SRC_URI="${G_URI}/filedir/inst/${RPM_N}.rpm doc? ( ${G_URI}/filedir/doc/AVG_7.5/LINUX_GROUP/AVG_Free_for_Linux/${DOC_N} )"
