Norbert Preining <prein...@logic.at> writes: > On Mo, 14 Mai 2012, Russ Allbery wrote:
>> isn't indicative of an error. A good way to indicate that is to unfuzz >> the patch. > Or build a source and binary package, do normal testing *as*usual* > and upload ... There was a reason why I added the word "subtle" in front of serious bugs. Duplicate code (the biggest risk of fuzzed patches) can do weird stuff, like create odd memory leaks or nasty heisenbugs (think of duplicating part of a mutex segment). It only takes a minute to unfuzz a patch, if that, and nearly all that time is spent inspecting the patch to be sure that it can be unfuzzed safely. quilt push -a Look for fuzzy patch warnings. For each fuzzy patch: quilt pop <patch> # inspect the fuzzy files to be sure everything is as expected quilt refresh Then: quilt pop -a svn commit # or VCS of your choice Of all the things that one has to do with a package, this is pretty minor. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- 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/87fwb20xiw....@windlord.stanford.edu