Bug#804169: RFS: libjreen/1.2.0-1
Am 06.11.2015 um 13:24 schrieb Gianfranco Costamagna:
Hi,
> yes, but let assume one of the libraries above have a security bug.
> you will need to do a source only upload, instead of just fixing the
> library and rebuild the affected packages (assuming there will be one
> day more packages using the above libraries you can always ship them
> as source only libraries, e.g.
> https://packages.qa.debian.org/w/websocketpp.html (unless the
> libraries are strictly internal and makes no sense outside this
> particular project)
I understand the problem. I've taken a look into the cmake file and I
found out that libjreen does not use "icesupport" automatically.
→ option(JREEN_USE_IRISICE "Use ICE from IRIS" OFF)
On the other side libjreen is looking for a external JDNS. And so it
would be really better to create a libjdns package for debian, or?
> I know, but you are Debian-patching an upstream issue. you are
> workarounding it, not fixing (even if it works). I would appreciate a
> proper fix and a patch sent upstream (in the meanwhile you can of
> course use this solution, It came in my mind, but I didn't suggest it
> because I don't think it is the best way)
Please correct me if I'm wrong, but I do not agree in your opinion
because other distributions uses another way of multiarch support.
For example openSUSE, they uses the path "/usr/lib64/libjreen.so.1". And
so I think it is impossible to upstream a patch, which changes
"DESTINATION lib${LIB_SUFFIX}" into "DESTINATION lib/${LIB_SUFFIX}"
because this would break the support for the other distributions.
I really do not know how to fix it to make it work for all
distributions. Any ideas?
> well, you can send patches upstream, it is fine by me to avoid debian
> patches as long as the mistakes are in the code and not seen by normal
> users (I can also accept a mistake in some obscure code that is mostly
> unreachable, but I would bother about sending bugs upstream and fix in
> a later release) cheers, G.
I've sent the the codespelling patch to upstream.
The cppcheck errors is only a "Uninitialized variable: c". I think this
is not critical.
Most of the "$ grep -riE 'fixme|todo|hack|xxx' ." errors occurs on
icesupport and this is unused. The rest is not critical, too.
Same on licensecheck. It does not affect this package.
Cheers,
Stefan
Reply to: