Re: How to find out why debuild -S dislikes dpkg-source --commit ?
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
Re: How to find out why debuild -S dislikes dpkg-source --commit ?
On Monday 30 November 2015 18:33:22 Thomas Schmitt wrote: > All is well as long as i have no debian/patches. I can build > and install the .deb files (debuild -S, debuild -b, dpkg -i). > > But if i make changes to the upstream files and run > debclean > dpkg-source --commit > then afterwards > debuild -S > fails with > dpkg-source: info: local changes detected, the modified files are: Hmm, you don't detail how you make a change to upstream files. With quilt you should start from a unmofidied source, then: - create the patch: quilt new my-brand-new-patch - modify whatever you need with *quilt edit* (very important): quilt edit path/to/foo.c quilt edit path/to/bar.c ... - tell quilt to record the changes: quilt refresh - put source back to original state (also quite important): quilt pop -a - edit the patch header according to dep-3 (recommended). Either: * cme edit dpkg-patch my-brand-new-patch * use your favorite editor and run "cme check dpkg-patch my-brand-new-patch" I don't remember if you need to commit debian/patches/* before running svn- builldpackage. I'll let you try on your side. Hope this helps Dod
How to find out why debuild -S dislikes dpkg-source --commit ?
Hi, after a few weeks of other leisures i came back to Debian packaging for a new upstream release of my software. Currently i feel plain stupid because i fail to install a patch which shall silence a few lintian warnings about the man pages. I unpacked the upstream tarball, moved it to the parent of the unpacked upstream tree and renamed it to libisoburn_1.4.2.orig.tar.gz. Then i copied the ./debian subtree from my local packaging svn instance into the unpacked upstream tree. I wrote a new version section into debian/changelog and removed an obsolete patch from debian/patches. All is well as long as i have no debian/patches. I can build and install the .deb files (debuild -S, debuild -b, dpkg -i). But if i make changes to the upstream files and run debclean dpkg-source --commit then afterwards debuild -S fails with dpkg-source: info: local changes detected, the modified files are: ... dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/libisoburn_1.4.2-1.diff.ARfBHF The file /tmp/libisoburn_1.4.2-1.diff.ARfBHF contains the reverse changeset of the patch which was created by dpkg-source --commit. All affected files have new timestamps and show the old content before my changes. I.e. the state as in libisoburn_1.4.2.orig.tar.gz The error abort of debuild -S persists even after a previous failed run restored the old content of the files. The problem vanishes only after i remove the patch. So i appears that my patch does influence the expectations of dpkg-source. But it either does not get applied after unpacking the source, or the result is in some way overridden by a later copying from original tarball. I created the work directory tree by cd ~ wget http://files.libburnia-project.org/releases/libisoburn-1.4.2.tar.gz cd ...path.../debian_dir tar xzf ~/libisoburn-1.4.2.tar.gz mv ~/libisoburn-1.4.2.tar.gz libisoburn_1.4.2.orig.tar.gz cd libisoburn-1.4.2 cp -a ...path.../svn/libisoburn/debian debian The last action copied the ./debian directory of the local SVN instance of svn://anonscm.debian.org/pkg-libburnia/trunk/libisoburn/ (Changes to ./debian will later be copied back and committed to SVN.) As said: Except the patching problem, this setup does what i expect. I deem it quivalent to what is described in https://www.debian.org/doc/manuals/maint-guide/first.en.html Am i wrong ? Have a nice day :) Thomas
