Re: Should I build a nmu for stable or a backport for wheezy-backports?
On Thu, Aug 8, 2013 at 6:25 AM, Rui Miguel P. Bernardo
<rui.bernardo.pt@gmail.com> wrote:
> On Wed, Aug 7, 2013 at 1:23 PM, Osamu Aoki <osamu@debian.org> wrote:
>> Hi,
>>
>> On Tue, Aug 06, 2013 at 08:17:03PM +0100, Rui Miguel P. Bernardo wrote:
>>> Hello list,
>>>
>>> let's say there is a bug in a stable package and that bug breaks the
>>> program functionality. Later the fix was uploaded to unstable/testing
>>> but never got in time for stable. For reference I'm talking about
>>> http://bugs.debian.org/679657.
>>>
>>> I tried 2 ways to solve this:
>>>
>>> a) I've downloaded the stable version of the package, applied the
>>> patch that fixed the problem and built a wheezy-backports package;
>>
>> What you described is the way we make stable updates. I have done this
>> kind of things.
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714759
>>
>> As you can see, it takes a bit more than usual efforts.
>>
>
> Yes, I think your example is exactly what needs to be done for
> syncevolution. I saw that the distribution in debian/changelog in your
> package upload is "stable", not -backports. That was one of my doubts,
> thanks.
>
>> Is this something all stable user needs to be exposed?
>>
>
> I think it is. The caldav/cardav sync functionality is currently
> broken on stable, testing and unstable. It doesn't renders the package
> unusable, but it is currently partially broken in all distributions.
>
> The situation, if I got it right, is that the patch exists in git but
> no package was released since the commit that fixes the bug was
> created in git. And because the next release of the package will
> include an upstream updated version, this leads to a backport
> solution, not a stable nmu upload, by the debian policy. The fix
> already existed in git at the time of the debian wheezy release, but
> no package was released back then, nor since then. I've just made a
> git cherrypick and applied it for my local build.
>
>>> b) I've downloaded the maintainers git repository (unstable), revert
>>> some commits and build a wheezy-backports;
>>
>> Usually, backport is simply recompiled version of "testing" package on
>> stable platform (with only dpkg/debheler updated to backport).
>>
>
> Ok.
>
>>> Backports exists for recent packages from unstable/testing that were
>>> adapted and rebuilt for stable. What I did in a) is not that: I have
>>> rebuilt a stable package and applied a patch.
>>
>> If you are doing it only for you, do it anyway.
>>
>
> I do. I just would like to turn the time spent on the issue and the
> fix into something usable for all. A little retribution to debian from
> me, if that's possible.
>
>>> If a) is not a backport is it a nmu then? Should I build a) as a
>>> stable nmu and try to search for a sponsor to upload it to stable? Can
>>> this be done?
>>
>> This is not A or B question. 2 different criteria.
>>
>
> Sorry for my writing... the question was really something like: if
> I've downloaded the source package from stable and applied a
> cherrypick to fix a bug. Now I clearly see that it is not a backport.
> I was trying to ask for a confirmation that it is a "stable nmu", not
> a backport.
>
> About the sponsor and the process to make a nmu I've found
> http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu-guidelines
> and http://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable
> . The process seems complicated...
>
>>> Or, to have a valid backport of the package, I MUST make b), which is
>>> to backport the testing/unstable package?
>>
>> testing. Please read backport docs.
>>
>
> Ok, testing only. Thank you for clarifying.
>
>>> What I'd like is to have the stable version of the package fixed in
>>> debian stable, where it is not working, not to have an upgraded
>>> package from backports.
>>
>> Please read Debian policy on stable update. You also need to cordinate
>> with the maintainer. You asking here indicate you have lots to learn.
>>
>
> Yes, I've read about it since yesterday in the links above.
>
> That a big process here: email maintainer and "stable release team"
> and report a bug against release.debian.org package, then get help and
> a sponsor, not mess up in the way... That would require some time, but
> it's feasible. I was wiling to do it.
>
> Although the above links suggest to try to contact directly with the
> maintainer, I'm not very comfortable doing it. He didn't reply to the
> bug report, why would he reply to me, an absolute stranger? And if he
> doesn't reply, I don't see the "stable release team" accept the nmu
> without the maintainers consent. Maybe I'm wrong?
>
> So I'm stuck here. I have a working package, ready, but I'm not sure
> which distribution I should add to the debian/changelog (my opinion is
> that it should be stable, since the source package was downloaded from
> there), and I see that the process is a bit complicated... I guess
> I'll just mail the bug report with my existing source package attached
> to just save some time to whoever stumbles on bug #679657.
>
> What messes with me is that I think it is not the first time that I
> see bugs in stable that were reported in testing and then do not get
> fixed in stable but through backports (if anyone does them), not
> through stable updates. IMHO I think that maybe this is not correct,
> if that's a debian policy.
>
>>> I hope this email is not to confusing as my doubts :) I'd like to have
>>> my doubts cleared because there is at least one more package
>>> (avelsieve) I'd like to upload, via nmu or backports, depending on the
>>> answers to my doubts.
>>
>> Good luck.
>>
>> Osamu
>
> I guess I'll just end up sending an email to the bug report with the
> fixed source package attached.
>
> Thank you for you valuable reply, Osamu.
>
> Rui Miguel
I must be tired... your example is just perfect and is what I needed
to try to fix the issue in stable. I'm going to do it in the next few
days.
Again, thank you Osamu.
Reply to: