Future of OMS support

[narc-Ontakac2]

Since I noticed that the Debian packages lack OMS support I have been looking into libmbus. The good news is that it is packaged and the remaining packaging issues are doable with reasonable effort. The bad news is that it became increasingly unmaintained over the years. So I doubt that my pull request to improve packaging will ever be pulled.

So my question is if it would make sense to maintain a fork as part of he volkszaehler project.

[r00t-]

i have no idea how many of our users are using OMS, and i guess that's the only thing to base such a decision on.
until #642 i was almost not aware that it existed in vzlogger.

[narc-Ontakac2]

There is now also #653. Looks like OMS is growing. Documents about the upcoming smart meter rollout also mention mbus.

[narc-Ontakac2]

OMS is also and important reason to not remove install.sh ( #624).

[narc-Ontakac2]

Looking closer at their pull requests it looks like the source code is getting a bit of maintenance while packaging and CI and the build are not. So a packaging fork might be an option.

[narc-Ontakac2]

@justinotherguy If I get a forked repository of https://github.com/rscada/libmbus in the volkszaehler organization I can use that as a packaging repository. This will have a master branch that is never modified and a packaging branch (named vzlogger or debian).

[justinotherguy]

after a quick look the project seems somewhat stale to me, too - at least regarding the debian package efforts.
I' went ahead and forked the repo: https://github.com/volkszaehler/libmbus

[narc-Ontakac2]

@justinotherguy Thanks for that, could you give me the same permissions for libmbus that I have for libsml?

The project is not completely stale, but it seems they have completely given up on packaging.

[narc-Ontakac2]

@justinotherguy I can push now, but I am missing privileges to deal with enviroments and actions:

[justinotherguy]

right - please give it another try now