Why vnstat is at version 1.12-1 only?

Hi,
This is my first post here so please go easy on me :smiley:

I noticed that vnstat in available at version 1.12-1 from 30-Aug-2014. The same version was available on Chaos Calmer 15.05(.1). The newest version of vnstat is 1.16, released 24-Dec-2016. That brings me to my three questions:

  1. Why this package wasn't updated to the newest available?
  2. Can this package be updated at all and can this be done before the soon-to-be-relesed 17.01?
  3. Are the bug fixes etc. from newer versions backported or something and that's why we're still at 1.12-1?

Thanks.

Maybe check with @jow, seems he has performed the last update.

I've send him an e-mail.
Thanks.

[quote="cybrnook, post:2, topic:1179"]
he has performed the last update.
[/quote]... and is marked as the "Maintainer" in the Makefile.

But the quickest way to get it updated might be that you do the version upgrade by yourself and then submit a pull request to Github packages feed so that Jow can just verify your work.

Updating packages takes effort. Feel free to contribute to it :wink:

I saw this, thanks but why is it in OpenWRT repo, not LEDE? Is it compatible with LEDE anyway?
The package for LEDE in packages-17.01 is still at 1.12-1.

[quote="r43k3n, post:5, topic:1179, full:true"]
I saw this, thanks but why is it in OpenWRT repo, not LEDE? Is it compatible with LEDE anyway?The package for LEDE in packages-17.01 is still at 1.12-1.
[/quote]The packages feed repo is common to Openwrt LEDE. It is that same repo.
The package has been updated in "master", but not in stable branches like Openwrt15.05 and LEDE-17.01
https://github.com/openwrt/packages/blob/master/net/vnstat/Makefile
https://github.com/openwrt/packages/blob/for-15.05/net/vnstat/Makefile
https://github.com/openwrt/packages/blob/lede-17.01/net/vnstat/Makefile

So, you get 1.16 from both Openwrt and LEDE buildbot snapshotsm, but 1.12 from the stable branches.

Not sure if @jow will backport the update to 17.01, but we will see. Possibly after the 17.01.0 release.

I'm new to building stuff and all this is quite confusing.
1.16 is available in snapshots but not stable and it will probably won't be available in 17.01.0. So the next stable release I can expect it available is 17.01.1?

What if I choose to build the packages from snapshot myself? Will it be compatible with the 17.01.0 or does it requite some of the "backporting" stuff you mentioned?

Is there a place like a wiki or something that's actually up-to-date, where I can read more about this stuff?

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.

About what stuff in particular?

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?

  1. Install vnstat

  2. Add your interfaces and start vnstat to create databases.

  3. 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

  4. Delete your current databases and restore them using --importdb function
    I use this:

vnstat -i eth0.2 --force --importdb "exportdb_eth0.2"

  1. Go back to vnstat and type vnstat to see the restored database. If you'll see "Error: eth0.2: Invalid database timestamp.", let us know.

@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.

Have you experienced the bug by yourself?

You are apparently quoting an upstream discussion, but you did not provide link to that discussion: https://github.com/vergoh/vnstat/issues/55

The lack of RTC should not have impact in normal situations, as the router will adjust time during the boot process with NTP.

Ps. I doubt that exporting/importing vnstat databases will be part of most users' usage of the package.

I am considering to simply roll back to v1.12 which is known working and tested.

I tested myself, although I haven't used vnstat earlier.

vnstat 1.16 complains about an invalid timestamp after importing a newly created and exported database. So, the upstream bug seems to be genuine.

Yes, I did.

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.

Don't you mean 1.12?

No I mean I reverted the "update to 1.16".

I get it now. Sorry. English is not my native language.

Can we get version 1.17 out now? It fixes the --import-db issue you found.