- Package:
- src:libsmi
- Source:
- libsmi
- Submitter:
- Tobias Frost
- Date:
- 2021-09-20 11:54:03 UTC
- Severity:
- wishlist
Upsteam has released 0.5.0 already in 2014. Would be cool to have this version as well in Debian. TIA!
❦ 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.
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.
❦ 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.
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?
❦ 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.
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!
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
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