dpkg-buildpackage OK, git-buildpackage not OK.

Guillaume Yziquel · External Since: Mar 11, 2009 Posts: 7

Hi.

I'm still on my OCaml-R packaging, pushing it slowly as my free times
allows it.

I've experienced a weird issue after a discussion with Mehdi Dogguy:
I've added a debian/clean file to remove two files from the source,
which are useless. Using dpkg-buildpackage works fine, and builds my two
binary packages. Using git-buildpackage seems to fail because of some
esoteric git/dh_clean issue.

Here's the full output. Advice appreciated.

> yziquel@seldon:~/sandbox/repo/debian/debian-ocaml/ocaml-r$ make git-buildpackage
> git clone git://git.debian.org/pkg-ocaml-maint/packages/dh-ocaml.git
> Initialized empty Git repository in /home/yziquel/sandbox/repo/debian/debian-ocaml/ocaml-r/dh-ocaml/.git/
> remote: Counting objects: 953, done.
> remote: Compressing objects: 100% (383/383), done.
> remote: Total 953 (delta 593), reused 833 (delta 512)
> Receiving objects: 100% (953/953), 168.21 KiB | 218 KiB/s, done.
> Resolving deltas: 100% (593/593), done.
> dh-ocaml/tools/dom-git-checkout ocaml-r
> I: cloning remote repository
> Initialized empty Git repository in /home/yziquel/sandbox/repo/debian/debian-ocaml/ocaml-r/ocaml-r/.git/
> remote: Counting objects: 134, done.
> remote: Compressing objects: 100% (125/125), done.
> remote: Total 134 (delta 65), reused 0 (delta 0)
> Receiving objects: 100% (134/134), 82.71 KiB, done.
> Resolving deltas: 100% (65/65), done.
> I: setting up remote tracking
> Branch upstream set up to track remote branch upstream from origin.
> Branch pristine-tar set up to track remote branch pristine-tar from origin.
> I: all done, enjoy.
> cd ocaml-r; git-buildpackage
> test -x debian/rules
> dh_testroot
> /usr/bin/make -C . -k distclean
> make[1]: entrant dans le répertoire « /home/yziquel/sandbox/repo/debian/debian-ocaml/ocaml-r/ocaml-r »
> Makefile:26: master.Makefile: Aucun fichier ou dossier de ce type
> ./config.status --recheck
> make[1]: ./config.status : commande introuvable
> make[1]: *** [config.status] Erreur 127
> make[1]: Échec de refabrication du makefile « master.Makefile ».
> rm -f *~ \#*\#
> cd src && /usr/bin/make clean
> make[2]: entrant dans le répertoire « /home/yziquel/sandbox/repo/debian/debian-ocaml/ocaml-r/ocaml-r/src »
> Makefile:26: ../master.Makefile: Aucun fichier ou dossier de ce type
> Makefile:142: .depend: Aucun fichier ou dossier de ce type
> rm -f .depend
> `ls *.ml *.mli | grep -v test_pa | grep -v pa_ocaml` > .depend
> /bin/sh: rdevices.ml : commande introuvable
> make[2]: *** [.depend] Erreur 127
> make[2]: *** Pas de règle pour fabriquer la cible « ../master..Makefile ».
> make[2]: Échec de refabrication du makefile « .depend ».
> make[2]: Échec de refabrication du makefile « ../master.Makefile ».
> make[2]: quittant le répertoire « /home/yziquel/sandbox/repo/debian/debian-ocaml/ocaml-r/ocaml-r/src »
> make[2]: entrant dans le répertoire « /home/yziquel/sandbox/repo/debian/debian-ocaml/ocaml-r/ocaml-r/src »
> Makefile:26: ../master.Makefile: Aucun fichier ou dossier de ce type
> make[2]: *** Pas de règle pour fabriquer la cible « ../master..Makefile ».
> make[2]: Échec de refabrication du makefile « ../master.Makefile ».
> rm -f *~ \#*\#
> rm -f *.a *.so
> rm -f *~ \#*\# *.cmo *.cmi *.cmx *.a *.o *.cma *.cmxa *.annot
> rm -f test.x
> make[2]: quittant le répertoire « /home/yziquel/sandbox/repo/debian/debian-ocaml/ocaml-r/ocaml-r/src »
> make[1]: *** [clean] Erreur 2
> make[1]: La cible « distclean » n'a pas pu être refabriquée à cause d'erreurs.
> make[1]: quittant le répertoire « /home/yziquel/sandbox/repo/debian/debian-ocaml/ocaml-r/ocaml-r »
> make: [makefile-clean] Erreur 2 (ignorée)
> rm -f debian/stamp-makefile-build
> dh_ocamlinit
> /usr/bin/make -f debian/rules reverse-config
> make[1]: entrant dans le répertoire « /home/yziquel/sandbox/repo/debian/debian-ocaml/ocaml-r/ocaml-r »
> make[1]: Rien à faire pour « reverse-config ».
> make[1]: quittant le répertoire « /home/yziquel/sandbox/repo/debian/debian-ocaml/ocaml-r/ocaml-r »
> if [ -d "." ]; then \
> cd . && QUILT_PATCHES=/home/yziquel/sandbox/repo/debian/debian-ocaml/ocaml-r/ocaml-r/debian/patches quilt --quiltrc /dev/null pop -a -R || test $? = 2 ; \
> fi
> Aucun patch retiré
> rm -rf ./.pc
> rm -f debian/stamp-patch*
> dh_clean
> rm -f debian/*.doc-base.apiref*
> dh_ocamlinit -d
> rm -f debian/stamp-autotools-files
> rm -f '/home/yziquel/sandbox/repo/debian/debian-ocaml/ocaml-r/ocaml-r/src/.depend'
> You have uncommitted changes in your source tree:
> # On branch master
> # Changed but not updated:
> # (use "git add/rm <file>..." to update what will be committed)
> # (use "git checkout -- <file>..." to discard changes in working directory)
> #
> # deleted: src/r_devices.c
> # deleted: src/rdevices.ml
> #
> no changes added to commit (use "git add" and/or "git commit -a")
>
> Use --git-ignore-new to ignore.
> make: *** [git-buildpackage] Erreur 1

All the best,

--
Guillaume Yziquel
http://yziquel.homelinux.org/

--
To UNSUBSCRIBE, email to debian-ocaml-maint-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org

Sylvain Le Gall · External Since: Oct 03, 2006 Posts: 138

On 27-10-2009, Guillaume Yziquel <guillaume.yziquel.DeleteThis@citycable.ch> wrote:
> Hi.
>
> I'm still on my OCaml-R packaging, pushing it slowly as my free times
> allows it.
>
> I've experienced a weird issue after a discussion with Mehdi Dogguy:
> I've added a debian/clean file to remove two files from the source,
> which are useless. Using dpkg-buildpackage works fine, and builds my two
> binary packages. Using git-buildpackage seems to fail because of some
> esoteric git/dh_clean issue.
>
> Here's the full output. Advice appreciated.
>
>> yziquel@seldon:~/sandbox/repo/debian/debian-ocaml/ocaml-r$ make git-buildpackage
>> git clone git://git.debian.org/pkg-ocaml-maint/packages/dh-ocaml.git
>> Initialized empty Git repository in /home/yziquel/sandbox/repo/debian/debian-ocaml/ocaml-r/dh-ocaml/.git/
>> remote: Counting objects: 953, done.
>> rm -f '/home/yziquel/sandbox/repo/debian/debian-ocaml/ocaml-r/ocaml-r/src/.depend'

[...]

>> You have uncommitted changes in your source tree:
>> # On branch master
>> # Changed but not updated:
>> # (use "git add/rm <file>..." to update what will be committed)
>> # (use "git checkout -- <file>..." to discard changes in working directory)
>> #
>> # deleted: src/r_devices.c
>> # deleted: src/rdevices.ml
>> #
>> no changes added to commit (use "git add" and/or "git commit -a")
>>
>> Use --git-ignore-new to ignore.
>> make: *** [git-buildpackage] Erreur 1
>

git-buildpackage do additional check to ensure that after a clean you
are back to pristine. It doesn't seems to be the case, because you have
deleted file.

You have different choices:
- really delete once and for all the files (either when importing from
upstream or by hand in one commit on branch master)
- save and restore files during the build

Regards,
Sylvain Le Gall

--
To UNSUBSCRIBE, email to debian-ocaml-maint-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org

Mehdi Dogguy · External Since: Jul 07, 2009 Posts: 7

Stefano Zacchiroli wrote:
>
> Still, this kind of errors are usually worrisome. In general, they mean
> that doing a "build"/"clean" cycle does not bring the source tree back
> in the same state as it was before starting the build. That might cause
> errors such as the infamous "FTBFS when built twice in a row".
>

It won't, in that specific case. The goal was to remove those files before
staring the build. So, an FTBFS related to those files is unlikely to
happen.

Note that this is not necessary anymore since Guillaume patched upstream's
Makefile to not use those files. Thus, keeping them in the tree doesn't
harm
and seems to be the easiest solution.

Cheers,

--
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/

--
To UNSUBSCRIBE, email to debian-ocaml-maint-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org

Guillaume Yziquel · External Since: Mar 11, 2009 Posts: 7

Mehdi Dogguy a écrit :
> Stefano Zacchiroli wrote:
>>
>> Still, this kind of errors are usually worrisome. In general, they mean
>> that doing a "build"/"clean" cycle does not bring the source tree back
>> in the same state as it was before starting the build. That might cause
>> errors such as the infamous "FTBFS when built twice in a row".
>>
>
> It won't, in that specific case. The goal was to remove those files before
> staring the build. So, an FTBFS related to those files is unlikely to
> happen.
>
> Note that this is not necessary anymore since Guillaume patched upstream's
> Makefile to not use those files. Thus, keeping them in the tree doesn't
> harm
> and seems to be the easiest solution.

As far as I see it, git-buildpackage does not go through to the "build"
target, and fails before. It seems to me that the "clean" target is
called first, rdevices.ml and r_devices.c are erased, and then git
complains that things do not look good. It doesn't seem to be a "cannot
build twice in a row"-type issue... since there's no building going on...

I do not understand precisely the logic of these steps. Does it mean
that putting upstream files in debian/clean is simply not something to
do since it alters the git repository at a time where upstream should
remain untouched?

So how should I erase these undesired upstream files?

All the best,

--
Guillaume Yziquel
http://yziquel.homelinux.org/

--
To UNSUBSCRIBE, email to debian-ocaml-maint-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org

Guillaume Yziquel · External Since: Mar 11, 2009 Posts: 7

Stefano Zacchiroli a écrit :
>
> You should fix that, so that "clean" does not remove those files (or,
> alternatively, you should ensure those files are not in the upstream
> tarball).

Thanks for the detailed explanation. It was background material that I
missed.

I'd rather not modify the upstream source package directly because I'm
not really comfortable with it, and also because it doesn't seem that
clean to me. using debian/clean was suggested as an alternative to
patches, since patches aren't really supposed to have as a purpose to
simply clean upstream source files.

But given what has been said, it seems to me that creating a patch that
cleans these files is the cleanest way I can come with.

Alternative, cleaner solutions are welcome, since patches are the
solutions I'll be adopting otherwise.

> As an additional advantage in fixing that, git-buildpackage will stop
> complaining; take that as a reward Smile

I will definitely take that as a reward.

> Cheers.

Thanks.

--
Guillaume Yziquel
http://yziquel.homelinux.org/

--
To UNSUBSCRIBE, email to debian-ocaml-maint-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org