<div dir="ltr"><div><div><div><div><div><div><div><div><div>Vincent and all,<br><br></div>About suffix<span style="color:rgb(0,0,0)"> </span><span class="im"><span style="color:rgb(0,0,0)">"~bpo8+1+b1" you've mentioned, it would still not work in my case, because resulting package version would be lower than one in Jessie! Let me take a practical example:<br><br></span></span></div><span class="im"><span style="color:rgb(0,0,0)">Package xfce4-mixer:<br></span></span></div><span class="im"><span style="color:rgb(0,0,0)">  * Current source version: 1.10.3-1 in both Jessie and Stretch<br></span></span></div><span class="im"><span style="color:rgb(0,0,0)">  * Current binary version in jessie: 1.10.3-1 (with xfce4-panel 4.10 dependency)<br></span></span></div><span class="im"><span style="color:rgb(0,0,0)">  * Current binary version in stretch: 1.10.3-1+b1 (with xfce4-panel 4.12 dependency)<br></span></span></div><span class="im"><span style="color:rgb(0,0,0)">  * Hypothetical binary version in jessie-backports: 1.10.3-1[X]~bpo8+1[Y] (with backported xfce4-panel 4.12 dependency)<br><br></span></span></div><span class="im"><span style="color:rgb(0,0,0)">My question is: where to put "+b1" in backported version? At position [X] or [Y]? Putting it in [Y] would result in a version number (1.10.3-1~bpo8+1+b1) lower than one in jessie (1.10.3-1). On the other hand, putting it at [X] would still result in a binary version</span></span><span class="im"><span style="color:rgb(0,0,0)"><span class="im"><span style="color:rgb(0,0,0)"> (1.10.3-1+b1~bpo8+1</span></span>) higher than one in jessie, but still lower than current one in stretch (1.10.3-1+b1).<br><br></span></span></div><span class="im"><span style="color:rgb(0,0,0)">About maintaining the whole XFCE 4.12 tree in jessie-backports, I'll keep on maintaining my own builds in OBS, eventually writing some scripts to keep track of changes in stretch and automate building and uploading backported packages whenever necessary. If I feel comfortable with the process, I will volunteer myself for maintaing it in jessie-backports. In the mean time, I still really appreciate if at least lightdm and lightdm-gtk-greeter (maintained by the same "Debian Xfce Maintainers" team) could be in jessie-backports in short term.</span></span><span class="im"><span style="color:rgb(0,0,0)"> Honestly, I only need backported xfwm4 4.12 (to better handling CSD-enabled apps), but I'm afraid it requires a full XFCE tree rebuild against 4.12 libs.<br></span></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-08-21 15:04 GMT-03:00 Yves-Alexis Perez <span dir="ltr"><<a href="mailto:corsac@debian.org" target="_blank">corsac@debian.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Aug 21, 2015 at 11:02:10AM -0700, Vincent Cheng wrote:<br>
> On Fri, Aug 21, 2015 at 5:26 AM, Laércio de Sousa<br>
> <<a href="mailto:laerciosousa@sme-mogidascruzes.sp.gov.br">laerciosousa@sme-mogidascruzes.sp.gov.br</a>> wrote:<br>
> > After investigating their current binary versions in stretch (I'm only<br>
> > watching on their source versions until now, and I'm not aware about binNMUs<br>
> > before), I just realized that a "+b1~bop8+1" could be a good suffix for<br>
> > those jessie packages that only need to be rebuilt against backported new<br>
> > libs.<br>
><br>
> No, a "~bpo8+1" suffix is still correct (it'll always be strictly less<br>
> than the version in stretch). If for whatever reason you need to<br>
> binNMU packages in backports, you can file binNMU bugs against the<br>
> <a href="http://release.debian.org" rel="noreferrer" target="_blank">release.debian.org</a> pseudopackage (the resulting packages will have a<br>
> suffix of "~bpo8+1+b1").<br>
><br>
> About backporting xfce 4.12 as a whole...have you discussed this with<br>
> the Debian xfce team yet? The initial backport may be manageable, but<br>
> is maintaining these backported packages for the entire lifetime of<br>
> jessie (and keeping them up-to-date with stretch) feasible? Are you<br>
> willing to handle all bug reports associated with these backported<br>
> packages?<br>
<br>
</span>Honestly, I'd really prefer people actually helping us with bugs and<br>
stuff like that (first in unstable, and let it migrate to testing and<br>
stable following the natural flow). And do stable uploads for things<br>
really needed, if they exists.<br>
<br>
Regards,<br>
<span class="HOEnZb"><font color="#888888">--<br>
Yves-Alexis Perez<br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><b>Laércio de Sousa</b><br></div><div style="text-align:center"><div style="text-align:left"><i>Orientador de Informática</i></div><div style="text-align:left"><u>Escola Municipal "Professor Eulálio Gruppi"</u></div><div style="text-align:left"><i>Rua Ismael da Silva Mello, 559, Mogi Moderno</i></div><i><div style="text-align:left"><i>Mogi das Cruzes - SP</i></div><div style="text-align:left"><i>CEP 08717-390</i></div></i></div><div><span style="font-family:arial;font-size:small">Telefone: (11) 4726-8313</span></div></div></div>
</div>