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...@gmail.com wrote: On Wed, Aug 7, 2013 at 1:23 PM, Osamu Aoki os...@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
Re: Should I build a nmu for stable or a backport for wheezy-backports?
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. Is this something all stable user needs to be exposed? 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). 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. 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. 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. 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. 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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130807122306.GA6078@goofy.localdomain
Re: Should I build a nmu for stable or a backport for wheezy-backports?
On Wed, Aug 7, 2013 at 1:23 PM, Osamu Aoki os...@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
Should I build a nmu for stable or a backport for wheezy-backports?
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; b) I've downloaded the maintainers git repository (unstable), revert some commits and build a wheezy-backports; 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 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? Or, to have a valid backport of the package, I MUST make b), which is to backport the testing/unstable package? 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. 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. Thanks -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cap1yx5zj+wut+pyowdcbbm4bxdvatwhfkxdkj9moz_se938...@mail.gmail.com
Re: Should I build a nmu for stable or a backport for wheezy-backports?
On 07/08/13 07:17, 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 think you'd be better off on the debian-mentors list. It's also the common place to ask for sponsors. Richard -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5201b4bf.90...@walnut.gen.nz
