Closed coldtobi closed 4 years ago
Right now, there is no such effort going on.
There were several issues recently field that can be traced down to an updated libUPNP (1.6.x with x > 22), e.g. #145 and #147. So I am a bit wary to update if newer versions of libUPNP are less stable. The current recommendation is to pin to 1.6.22 as this seems to be the last stable version of libUPNP.
Would changing the code to compile with 1.8 still work with the 1.6.x versions of libUPNP ? Mostly concerned here that it still can be compiled with old/new versions in the transition period in which distributions are on different version levels. If things can be #ifdef
-ed, that would be fine by me.
So if that is cleared, and maybe the crashes in newer libUPNP can be explained by accesses to private structs, I am happy to accept pull requests.
OK, thanks for the feedback! I still need to investigate all the bits about the update to the 1.8 version, but as far as I can see it might be possible to write code for >1.6.24 to be compatible with 1.8 by using accessor functions introduced in that version, but that obviously won't work for 1.6.22 without #ifdefs and stuff...
Said that, at least for the crash, there was a bug in the Debian package, fixed in Debian version 1.6.24-2 that could have caused this, but the backtrace of the report in #147 does not have symbols to really tell...
(For Debian it will not possible to pin to a specific libupnp version, so I will try to come up with a patch for 1.8, but I cannot tell now when it will be ready)
Note: libupnp 1.8 landed in Fedora this week and now I also have problems getting this packaged in Fedora.
Hi,
I've received a bug in Debian about libupnp 1.8: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884246
Are there already plans / code patches to update it to this version of libupnp? (Just asking to avoid double work, I couldn't find code for it)
Many thanks for any pointers!