Lucas Nussbaum <lu...@lucas-nussbaum.net> writes: > On 20/12/11 at 23:16 +0000, brian m. carlson wrote: >> On Tue, Dec 20, 2011 at 09:36:47PM +0100, Lucas Nussbaum 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. Fixing >> > > this was a lenny release goal, maybe it should be one again?!? Most >> > > importantly, maybe someone who has access to one of those build grids >> > > can run the old tests again, because I feel by accidentally stumbling >> > > upon these problems we will not be able to find and fix many of them any >> > > time soon. >> > >> > Is it really worth it? There are many ways to work-around this, such as >> > using a temporary git repo to be able to 'git clean' and return to a >> > clean state before each build. >> >> 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. > > 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 that could be used instead to fix problems > affecting our users. > > Maybe it's better to fix those bugs when they are encountered, rather > than have a systematic effort to fix them all?
I think it is beter to have them fixed before someone needs to write a patch for them. The way I prepare a patch for a debian package goes like this: 1. apt-get source (or git/svn) 2. debuild -us -uc -b (see if it actually builds before changes) 3. dch --nmu 4. edit files 5. debuild 6. dpkg -i && test 7. go back to 4 till it works 8. debuild -us -uc -S 9. rename debain/patches/debian-changes-version or debdiff the dsc files 10. reportbug -A patch package If the package does not build N times then steps 4/5/6 are more work. But also step 9 often becomes much more work. The patch becomes a lot larger, usualy because auto* files are included, and then needs extra cleanup before being able to send it. > If you are interested into mass bug filing about issues that affect our > users, see http://lists.debian.org/debian-qa/2011/08/msg00091.html for a > list of 1073 packages failing to install, remove, or upgrade from > squeeze. How large is the intersection of those 1073 with the packages that don't build multiple times? Lets fix that subset first. Easier to fix 2 bugs with a single upload. :) > Lucas MfG Goswin -- 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/87pqfiuiqq.fsf@frosties.localnet