<html><head></head><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:8px"><div id="yiv1982194849"><div id="yui_3_16_0_ym19_1_1471862373533_3689"><div style="color: rgb(0, 0, 0); font-family: HelveticaNeue, "Helvetica Neue", Helvetica, Arial, "Lucida Grande", sans-serif; background-color: rgb(255, 255, 255);" id="yui_3_16_0_ym19_1_1471862373533_3688"><div id="yiv1982194849yui_3_16_0_ym19_1_1471861944801_3231" style="font-size: 8px;"><span id="yiv1982194849yui_3_16_0_ym19_1_1471861944801_3534"><font id="yiv1982194849yui_3_16_0_ym19_1_1471861944801_3644" size="3">Hey G, charle</font></span></div><div id="yiv1982194849yui_3_16_0_ym19_1_1471861944801_3231" style="font-size: 8px;"><span><font size="3"><br clear="none"></font></span></div><div id="yiv1982194849yui_3_16_0_ym19_1_1471861944801_3231" style="font-size: 8px;"><font id="yiv1982194849yui_3_16_0_ym19_1_1471861944801_3708" size="3">Take a look at libretro website, they intent to unify all the HLE plugins (glide64, rice, glideN64...). In the long goal they'll have only one HLE graphic plugin, as well one LLE plugin (which is working right now, it's the Vulkan backend), it'll diverge more and more anyway in the future. So if you wanna merge it to upstream, good luck, libretro team tried and upstream refused a long time ago (when it was more a shallow fork); if upstream is receptive, we send back stuff to them directly, like I did with genesis plus gx some days ago.</font></div><div id="yiv1982194849yui_3_16_0_ym19_1_1471861944801_3231" style="font-size: 8px;"><font size="3"><br></font></div><div id="yiv1982194849yui_3_16_0_ym19_1_1471861944801_3231" dir="ltr"><font size="3" id="yui_3_16_0_ym19_1_1471862373533_4090">regards,</font></div><div id="yiv1982194849yui_3_16_0_ym19_1_1471861944801_3231" style="font-size: 8px;"><font size="3" id="yui_3_16_0_ym19_1_1471862373533_4148">sergio-br2</font></div> <div class="yiv1982194849qtdSeparateBR" id="yui_3_16_0_ym19_1_1471862373533_3933" style="font-size: 8px;"><br clear="none"><br clear="none"></div><div class="yiv1982194849yqt5331756249" id="yiv1982194849yqt72922" style="font-size: 8px;"></div></div></div></div><div class=".yiv1982194849yahoo_quoted"> <div style="font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:8px;"> <div style="font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px;"> <div dir="ltr"><font size="2" face="Arial"> Em Segunda-feira, 22 de Agosto de 2016 6:51, Gianfranco Costamagna <locutusofborg@debian.org> escreveu:<br clear="none"></font></div> <br clear="none"><br clear="none"> <div class="yiv1982194849y_msg_container">control: tags -1 wishlist<div class="yiv1982194849yqt5446981091" id="yiv1982194849yqtfd01762"><br clear="none"><br clear="none">> Then please integrate your changes in upstream mupen64plus. Many<br clear="none">> "forks" are now removed from debian (I think mutt-patched is one of<br clear="none">> the recent ones) and now you start to introduce new ones - against the<br clear="none">> Debian policy</div><br clear="none"><br clear="none">this is completely correct, the goal for this package is/should be integrating it in<br clear="none">the original mupen64plus.<br clear="none">But until that day, this package has a reason to exist, and to be in Stretch.<br clear="none"><br clear="none">the Debian policy in this case is not specifying a "must", but a "should" instead<br clear="none">(and we can also discuss if this is a convenience code copy, because the code is different)<br clear="none"><br clear="none">"Some software packages include in their distribution convenience copies of code from other software packages, generally so that users compiling from source don't have to download multiple packages. Debian packages should not make use of these convenience copies unless the included package is explicitly intended to be used in this way.[29] If the included code is already in the Debian archive in the form of a library, the Debian packaging should ensure that binary packages reference the libraries already in Debian and the convenience copy is not used. If the included code is not already in Debian, it should be packaged separately as a prerequisite if possible. [30]"<br clear="none"><br clear="none">there is no "must" word, so the correct severity is wishlist<br clear="none">(and please don't start a ping/pong severity game, thanks).<br clear="none"><br clear="none">Sergio discussed this on debian-mentors, and a few DD agreed that the severity is not RC, hence I'm downgrading it right now.<br clear="none"><br clear="none">thanks for the bug report, I hope it will be eventually fixed and this package removed.<br clear="none"><br clear="none">G.<div class="yiv1982194849yqt5446981091" id="yiv1982194849yqtfd69378"><br clear="none"></div><br clear="none"><br clear="none"></div> </div> </div> </div></div></body></html>