This is a version bump for vnStat in order to get a more current version into portage. The ebuild conforms with FHS unlike the 1.1 version. <changelog> 1.3 / 8-Mar-04 - Fix: support for 64bit counters - Fix: 'yesterday' was showing 01.01. with new databases - Fix: free space warning changed from 1% to 1MB - Fix: minor security exploit - A man page has been included - Hourly output with textgraphical view - kBs are visible when traffic is under 1000 MB - Webpage moved to http://humdi.net/vnstat/ - Minor visual updates </changelog>
Created attachment 27351 [details] vnstat-1.3.ebuild
# emerge /usr/portage/net-analyzer/vnstat/vnstat-1.3.ebuild Calculating dependencies ...done! >>> emerge (1 of 1) net-analyzer/vnstat-1.3 to / !!! No package digest file found: /usr/portage/net-analyzer/vnstat/files/digest-vnstat-1.3 !!! Type "ebuild foo.ebuild digest" to generate it. # ebuild vnstat-1.3.ebuild digest >>> Generating digest file... <<< vnstat-1.3.tar.gz >>> Generating manifest file... <<< vnstat-1.3.ebuild <<< ChangeLog <<< vnstat-1.1.ebuild <<< files/digest-vnstat-1.1 <<< files/digest-vnstat-1.3 >>> Computed message digests. # emerge vnstat-1.3.ebuild Calculating dependencies ...done! >>> emerge (1 of 1) net-analyzer/vnstat-1.3 to / >>> md5 src_uri ;-) vnstat-1.3.tar.gz >>> Unpacking source... >>> Unpacking vnstat-1.3.tar.gz to /var/tmp/portage/vnstat-1.3/work gzip: stdin: not in gzip format tar: Child returned status 1 tar: Error exit delayed from previous errors !!! ERROR: net-analyzer/vnstat-1.3 failed. !!! Function unpack, Line 332, Exitcode 2 !!! failure unpacking vnstat-1.3.tar.gz
I'm unable to reproduce that error even after trying with 3 different hosts. The md5 for vnstat-1.3.tar.gz is f0a80320b57fc44c08320dd07aedb830, check if it's the same in the digest.
1: 955577c4684ead13036ec8b002c6e89f vnstat-1.3.tar.gz # ls -la vnstat-1.3.tar.gz 112640 Mar 16 16:48 2: f0a80320b57fc44c08320dd07aedb830 vnstat-1.3.tar.gz # ls -la vnstat-1.3.tar.gz 26049 Mar 8 16:06 That is really weird. Don't get how the first one was bigger but redownloaded and no problem working fine now. Good work keep it up!
I just tested the ebuild (and vnstat-1.3) and it works fine on my system. (Just in case you want to get a comment of an additional tester.)
Created attachment 28064 [details] vnstat-1.4.ebuild vnStat 1.3 had output problems with some systems (although not Gentoo), so 1.4 contains only bugs fixes. The only change in the ebuild is the version number.
I tested the ebuild for vnstat-1.4 half an hour ago. Works fine here, no problems on my system (as expected :-) ).
Just out of curiosity, why isn't this newer version included in the general portage tree yet? I installed version 1.1 from the portage tree but that e-build did not install the file in /etc/cron.d/vnstat that is logging the traffic so it didn't work out of the box. Also the default path for vnstat is different from the 'standard' default install path of vnstat so the crontab file must be edited (must read /usr/bin/vnstat instead of /usr/local/bin/vnstat
What about adding some code to the pkg_postinst() portion of the ebuild to move the vnstat db files if users are upgrading from 1.1 to 1.4? Here is the quick-n-dirty code I used: pkg_postinst() { if [ -d /var/spool/vnstat ] ; then # Move data to new location mv -f /var/spool/vnstat/* /var/lib/vnstat && rmdir /var/spool/vnstat # einfo to inform user that db files moved. einfo "vnstat db files moved from /var/spool/vnstat to /var/lib/vnstat" fi } (I added an if-then condition to my previous hack). And defining S=${WORKDIR}/${P} is redundant since portage already defaults to that.
Why isn't this ebuild in portage?
Created attachment 32754 [details] vnstat-1.4.ebuild (updated)
Ok, updated the ebuild so that it includes compatibility for the 1.1 ebuild. Any other reasons why this shouldn't be in portage?
cleaned up your 1.4 ebuild (dont strip the header comments out next time) and added to portage netmon doesnt exactly have a lot of developers so we cant get to everything :P
The clean up (comment 13) of the cron entry causes problems with interfaces that can transfer 4GB in less than an hour because the 32bit kernel counter will wrap before vnstat can see the change. The cron will also start producing errors if the user enables the cron, uninstalls vnstat and forgets to disable the cron again ("vnstat: command not found"). Reproducible: Every time when there's enough traffic Steps to Reproduce: 1. wait for vnstat to update or update manually 2. transfer at least 4GB before next update 3. compare the logged value from vnstat to actually transferred value Actual Results: vnstat shows at least 4GB less than there was traffic Expected Results: vnstat shouldn't miss traffic Could the netmon herd assign this to vapier@gentoo.org since he requested to do so? Seems that I can't change that field.
Created attachment 34046 [details] vnstat-1.4-r1.ebuild Added a check for /etc/cron.d so that the original cron gets installed if the directory exists (and it can be assumed that vixie-cron is in use). If the original cron isn't installed, einfo will show a note about the 4GB problem.
Created attachment 34047 [details] files/vnstat.cron replacement Instead of requiring the user to comment out "exit 0", I think it's better to check if the vnstat binary exists and if there's any database available (= the user has started monitoring an interface). This approach will also automatically disable the cron if vnstat is uninstalled.
updated cron file and have it install into cron.d
*** Bug 52102 has been marked as a duplicate of this bug. ***
