Hi, Dominique Dumont wrote: > Hmm, you don't detail how you make a change to upstream files.
By editing texts with vim or by copying files from my workstation into the libisoburn-1.4.2 tree of my Sid VM. At occasion of release 1.4.0 i afterwards naively applied "debuild -S", which told me to run "dpkg-source --commit" first. This worked fine three months ago. But it seems to be a bad advise if already a patch exists. Meanwhile i succeeded with production and use of two patches by operating quilt directly as shown in https://www.debian.org/doc/manuals/maint-guide/modify.en.html -------------------------------------------------------------------- Current theory about the original problem: I get the impression that "dpkg-source --commit" yields a good result only if - debian/patches contains no patches yet, - and the directory libisoburn-1.4.2/.pc does not exist. (It gets created in the course of "dpkg-source --commit" or "debuild -S". Sometimes it survives the run of "debuild -S". Sometimes it is gone afterwards. I fail to recognize a pattern.) This explains why my single patch for 1.4.0-{2,3} worked. My first patch to 1.4.2-1 would probably have worked if not the .pc directory had remnants of the previous 1.4.0 patch. (Still unclear how it sneaked into my new 1.4.2 tree. I dimly remember to have run "debuild -S" prematurely, when the 1.4.0 patch was still in the debian/patches directory.) Whatever, outdated .pc or not: The second "dpkg-source --commit" patch reproducibly spoils the subsequent runs of "debuild -S". The patches apply to disjoint file sets. So i can juggle with them: If i reduce debian/patches/series to a single line and remove .pc, then each of the "dpkg-source --commit" patches works. As soon as i add the second patch name to the series file, "debuild -S" complains and demands me to revert that second patch. -------------------------------------------------------------------- I added the quilt gestures to my cheat sheet and will not use "dpkg-source --commit" any more. Have a nice day :) Thomas
