[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Reporting of bugs in package VCS repos


On Sat, Apr 26, 2014 at 11:45:00AM +0900, Charles Plessy wrote:
> Le Thu, Apr 24, 2014 at 10:26:20AM +0200, rf@q-leap.de a écrit :
> > 
> > Thanks Charles, that helped. Now I just have a remaining problem, when I
> > want to create the source package. The fastx-toolkit_0.0.14.orig.tar.gz
> > created by "pristine-tar checkout fastx-toolkit_0.0.14.orig.tar.gz"
> > is not consistent with the upstream source generated by
> > "git archive 0.0.14 | | tar -xf -". I obtain the following errors when
> > trying to build the source package after a successful build of the
> > binary packages:
> > 
> > dpkg-source: info: using source format `3.0 (quilt)'
> > dpkg-source: info: building fastx-toolkit using existing ./fastx-toolkit_0.0.14.orig.tar.gz
> > dpkg-source: error: cannot represent change to debuild/INSTALL:
> > dpkg-source: error:   new version is symlink to /usr/share/automake-1.11/INSTALL
> > dpkg-source: error:   old version is nonexistent
> > dpkg-source: error: cannot represent change to debuild/config/ltmain.sh:
> > dpkg-source: error:   new version is symlink to /usr/share/libtool/config/ltmain.sh
> > dpkg-source: error:   old version is nonexistent
> Dear Roland,
> the files triggering the error of dpkg-source are not present in the orignal
> source archive: they have been auto-generated during a previous build.
> As a control, you can build the package from a fresh git clone, using the same
> fastx-toolkit_0.0.14.orig.tar.gz file, and you will see that it works.
> To remove the autogenerated file, I usually reset the repository with
> the following commands:
>  - git clean -fdx  # Erases any file that is not known (no commit) in the Git
>                    # repository.
>  - git checkout .  # (from the top directory).  Restores all files to their
>                    # original contents, that is, revert all non-committed changes.
> Needless to say, before running these commands, one needs to ensure that if there
> are valuable changes in the debian directory, they will be kept.  I usually
> “stage” these changes with the “git add” command.

While this git based method works I'd recommend rather to mention these
autogenerated files in the file


which will remove them in the Build process.  The rationale is that it
is best packaging practice that packages will build twice in the row and 
people usually expect this to work independently from the VCS which is
(by chance) used for maintaining a package.  If you can get this done
cheaply by just removing them via debian/clean I see no point in using
non packaging tools (like git).

Kind regards



Reply to: