#991813 libsmi: New upstream version 0.5.0 available.

#991813#5
Date:
2021-08-02 12:02:32 UTC
From:
To:
Upsteam has released 0.5.0 already in 2014.
Would be cool to have this version as well in Debian.

TIA!

#991813#10
Date:
2021-08-02 17:54:48 UTC
From:
To:
 ❦  2 August 2021 14:02 +02, Tobias Frost:

I don't remember why I didn't package but I remember there was some
"good" reason. I think there is an ABI incompatibility but it is not
reflected in the ABI number (VERSION, REVISION and AGE stays the same).
I may have contacted upstream on the mailing list about this, but all I
can find is me asking about what's new in this 0.5.0 because no
changelog, no announce, not listed on the official website and got no
answer. So, maybe, there is no issue at all.

#991813#15
Date:
2021-08-03 05:42:22 UTC
From:
To:
CMake transition branch they even require it.)
with some patches on top (some might be interesting for upstream, I still have to check)
More concrete, I'm bitten at least by https://bugzilla.redhat.com/show_bug.cgi?id=975879.
This issue is very annoying as it prevents using libsmi being used from C++ without severere hackery.
it is fixed in 0.5.0 by https://gitlab.ibr.cs.tu-bs.de/nm/libsmi/-/commit/d112498b73c70bea37280d4fd3669f911cf77c87

There are also other nice to have fixes, some prevents crashes, some code no
longer relying from undefined behaviour etc; some even after the 0.5.0.

So -- my 2 cent -- I would even package trunk of the git repo, it would
be much better than the more-than-adecade(!) old version in Debian.

Regarding ABI: I've diffed the 0.4.8 smi.h with the 0.5.0 one:
all those changes should not be ABI changing.

#991813#20
Date:
2021-08-03 05:54:26 UTC
From:
To:
 ❦  3 August 2021 07:42 +02, Tobias Frost:

If you have some time, feel free to take over the package. I have too
much on my plate currently.

Thanks for checking. If you don't want to take over the package, I'll
try to find some time to update to 0.5.0.

#991813#25
Date:
2021-08-03 06:33:17 UTC
From:
To:
Lets form a team or maybe ask the net-snmp people if they would be ok
in expanding the scope towards are more snmp team?

#991813#30
Date:
2021-08-03 08:13:05 UTC
From:
To:
 ❦  3 August 2021 08:33 +02, Tobias Frost:

Whatever you see fit. I don't think the SNMP team has much bandwidth
either, so I wouldn't go through the trouble.

#991813#35
Date:
2021-08-03 08:48:00 UTC
From:
To:
Dear net-snmp maintainers,

I'm pondering with packaging snmpb [1] and its dependencies
netsmp++ [2] and an updated libsmi [3].

Best of course would be that the packages would be team maintained,
so I'm wondering if the net-snmp would be open to the idea to expand their
scope to handle also such packages.

Let me know, you thoughts!

#991813#40
Date:
2021-08-09 11:25:55 UTC
From:
To:
their

Hi Tobi,
  I don't think there really is much of a team. Not sure what happened (my
working theory is they all finally understood how to read ASN.1 and went
mad in the process).
I think I'm all that's left as far as active maintainers. The email list
has 5 members.

However, I'm willing to help. There's probably some overlap in the strange
sort of bugs snmp can bring.
The other complexity is that net-snmp uses the old style type of team, see
https://wiki.debian.org/Alioth/MailingListContinuation .  Looking into it,
I really should move it to the new-style team maintainership (like how the
Python team works).
I don't think it would be a good idea to make a new package use an
old-style team.

I'm not sure of your timings, but I probably should actually start to move
net-snmp onto the new style team. It would have been nice to do this before
the freeze but we are here now.

 - Craig

#991813#45
Date:
2021-09-20 11:49:29 UTC
From:
To:
Hi,
  I have now updated net-snmp to use the new style teams. You'll see that
the control file is now:

Maintainer: Debian SNMP Team <team+snmp@tracker.debian.org>
Uploaders: Craig Small <csmall@debian.org>,
Thomas Anders <tanders@users.sourceforge.net>,
Noah Meyerhans <noahm@debian.org>

You can use the same maintainer if you like, its a generic SNMP team rather
than net-snmp specific, though of course at the moment its the only package
in that team.
The uploaders of course would be different for your package.

 - Craig

(my
strange
see
it,
the
move
before