It will be available in 17.01.0 too once I get around to backport it
No, it will be available in any 17.01.* release as soon as I get around to backport it. Non-essential. non-core packages are continuously rebuilt for stable releases.
It will be compatible, in fact you can also simply install the .ipk fromsnapshots on a release. This is similar to installing a debian testing package on a debian stable system which usually works okay as long as the dependencies aren't too complex.
Branches, tags, building, backporting etc.
I'd like to contribute but I would prefer to just read about stuff and ask questions if I'll have any, rather then to ask about every single thing.
What is the protocol for asking to downgrade package?
I think i found a bug in the 1.16 version of vnstat. @jow - Can you help out?
1.16 introduced database validation before file write and when loading a database after I got one report of a situation where the cached database got somehow corrupted in memory which then resulted in data getting corrupted in the written database itself.
I think that the lack of RTC clock in most routers might be responsible for failings to verify database timestamp causing vnstat to reject the whole database.
Would anyone be maybe willing to check that out and try to reproduce the error?
Install vnstat
Add your interfaces and start vnstat to create databases.
Stop vnstat and create --exportdb backup of the database
Here's what I use. Feel free to adjust it to your needs. The backup will be created in your current location.
vnstat -i eth0.2 --exportdb > exportdb_eth0.2
Delete your current databases and restore them using --importdb function
I use this:
@jow Since you're a maintainer for this package did you maybe had some time to think about this? I don't think vnstat 1.16 should be available in 17.01 when it becomes stable. I'm thinking we could go with 1.15 for the 17.01 and then upgrade it to 1.17 for 17.06 when the vnstat developer will have a chance to fix this or at least introduce an option to disable timestamp verification.
Sooner or later this will become a bigger issue when more people will switch to LEDE 17.01 for good. Maybe we could have this sorted out before RC2 or RC3 if you're guys planning it.
It's considered a backup solution and it's recommended to use it someone would want to import their databases in to vnstat 2.0 that's being worked on now.
Yes, it is "known working" but there are also bugs that are fixed in newer releases. Ubuntu for example uses 1.14 in their LTS release. Just because the newest release has a bug, doesn't mean we should stay with release from 2014. From the vnstat developer quote I posted above you know this problematic feature was introduced in 1.16 so all we have to do is go back to 1.15 and we're good.
We wouldn't even need to discuss the version if vnstat package was updated sooner. I'm not accusing anyone. We're still in RC so we have some time to test everything. I use vnstat so I can test 1.15. No problem there. If you're really worried about possible issues then you can always go with 1.14 that's being used in Ubuntu 16.04 LTS.
Great! Well... kind of. The bug is confirmed but it mean's it's there.
I reverted the update to 1.16 now. If you want see vnstat updated, please send a tested pull request to the Github packages repository. I will to hand over maintainer ship to whoever is interested.
Thanks. I installed vnstat_1.17-1_arm_cortex-a15_neon-vfpv4.ipk and vnstati_1.17-1_arm_cortex-a15_neon-vfpv4.ipk on my Netgear R7800 with LEDE 17.01.2 and it is working fine.
I see that you referred @mooninite to the vnstat 1.17.x release.
Have you tried it yourself? What's your experience. I'm a newbie who's a bit scared of doing such an upgrade and wanna see other people jump off the diving board before I do.
@mooninite,
When you made the upgrade to vnstat 1.17.x, did you lose any vnstat logs/stats/database?
Thu Aug 10 18:07:51 PDT 2017 update: did you first have to remove/uninstall your older/current vnstat? If so, doesn't uninstalling vnstat remove all the vnstat logs/stats/database?
