On 23/12/11 at 11:16 +0100, Jakub Wilk wrote: > >>>On 20/12/11 at 22:01 +0200, Peter Eisentraut wrote: > >>>>With recent dpkg(-source) changes, many packages are again > >>>>failing to build twice in a row, because of uncommitted > >>>>upstream changes. > > Yes, I'd expect that the situation is much worse than it used to be. > Not only because of dpkg-source changes, but also due to ubiquity of > build tools that throw away build tree after build (pbuilder, > sbuild, $VCS-buildpackage...). > > >On 20/12/11 at 23:16 +0000, brian m. carlson wrote: > >>If I'm fixing an RC bug, it's very convenient to be able to test > >>a patch and then rebuild with a different patch if necessary. If > >>the package doesn't build cleanly N times in a row, or if there > >>are other problems with the packaging that make it difficult to > >>fix, I usually go on to fix other bugs instead. Also, when I > >>file a bug report, the harder you make it to fix your package, > >>the less likely you are to receive a patch with that report, > >>workaround or not. > > Same here. > > * Lucas Nussbaum <lu...@lucas-nussbaum.net>, 2011-12-21, 10:41: > >I'm not saying that it's not convenient. But on the other hand, > >several hundreds of packages probably need to be fixed, which will > >require a large amount of manpower > > Well, hopefully there are still some non-MIA maintainers left, that > can take care of their own packages. And it's not like these bugs > would be RC, or that we'd have a dead-line to fix them all. Also, > such bugs would be useful even if they were not going to be fixed, > because they'd act as a warning for people trying to modify the > package. > > >that could be used instead to fix problems affecting our users. > > You seem to assume that this manpower is somehow transferable to > other tasks. I'm afraid that the result of telling people "don't fix > FOO, do fix BAR instead" can be that neither FOO[0] nor BAR[1] is > fixed.
It is transferrable to some level: "fails to build twice" bugs are quite similar to "fails to build" bugs, and we have a large amount of such bugs (501 packages failing to build in my latest rebuild). Anyway, if people are willing to work on that, why not. I would prefer if those bugs were filed with severity:minor, and if that effort was not a release goal. I could do one test rebuild for that effort, too. For that to happen, I need a patched sbuild that does what you want to test. I don't care if the patch is dirty: the patched sbuild doesn't need to permit "normal" builds, so feel free to hack deep inside. Back in 2007, the required sbuild patch was about 10-lines long (patch can be found in collab-qa svn, in debcluster/configs/sbuild-twice.patch). Make sure the patch works by testing it against a reasonable amount of randomly chosen packages. Then I would provide the logs (but do not file bugs myself). Lucas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111223151405.ga24...@xanadu.blop.info
