Bug#804169: RFS: libjreen/1.2.0-1
Hi Stefan,
>3) Sorry, I do not understand how to pack the 3rdparty libraries
>separately. The libraries are not compiled and Jreen only needs them for
>compile itself and they are not shipped in the package afterwards.
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)
>4) done – I've change your suggestion a bit to avoid patching cmake by
>using a "/" before "$(DEB_HOST_MULTIARCH)"
>
>→ dh_auto_configure -- -DLIB_SUFFIX=/$(DEB_HOST_MULTIARCH)
>
>It works!
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)
>5) The file ./alttoolbar_rb3compat.py: does not exists in the source. It>looks like you mix me up with someone else, maybe the maintainer of the
>"rhythmbox-plugin-alternative-toolbar"?
yes, bad copy-paste :)
>Ok, I've checked up the spelling and code errors and I can confirm them,
>but I'm not the developer of jreen. Do I have to patch this mistakes as
>maintainer, too? Most of the errors occurs at the 3rdparty tool
>"icesupport".
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.
Reply to: