Re: many packages fail to build twice in a row again
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 <lucas@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
Reply to: