On 07.12.20 18:49, Steffen Möller wrote: > On 07.12.20 16:53, Nilesh Patra wrote: >> Hi, >> >> On Mon, 7 Dec, 2020, 9:03 pm Steffen Möller, <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hello, >> >> That cleaning I had introduced between the builds somewhen was removed >> and to avoid some ping-pong I thought we should talk about it. I >> presume >> this is because of some system setting that runs cowbuilder when I run >> it within the source tree. Can routine-update please somehow test for >> that and give a warning to change the local configuration if we decide >> not to clean? >> > Ok. I now found also this message that Andreas left me in the source tree: > > # This should *NOT* be default! The script is for users who are doing > *proper* > # builds in a chroot environment and do not want to bloat their local > systems > # with unneeded Build-Depends. Steffen, if you really want this please find > # some command line option to trigger it > #if ! dpkg-checkbuilddeps; then > # echo "E: This machine misses above packages as build dependencies. If > the package is already in Debian then run" > # echo " sudo apt-get build-dep" > # echo " to install what is missing and invoke $(basename $0) again, > perferably from within $(pwd) with no arguments to spare redundant > downloads." > # exit 1 > #fi > > It is a fairly clear indicator that something works different on my > system tham on Andreas'. > > "gbp buildpackage -S" indeed needs all dependencies to be installed, > even though the build (for which all dependencies are installed again) > is happening via cowbuilder. A bit annoying, but I can live with it. > "gbp buildpackage --git-pbuilder -S" would also perform .dsc creating > via pbuilder. So, the root of the problem I dare to locate in expecting > a particularly defined gbp.conf somewhere on the systems. Is that > correct? If so, then routine-update should check for that. Preferably, > it should require that external configuration and directly set all flags > that are required. > >> Here what it looks like for me, i.e. a perfect build that has the >> routine interrupted: >> >> >> So looking at the last commit message "ready to upload to unstable" it >> looks like routine-update did it's work well. > Yes. >> What is interrupted is fundamentally gbp instead. >> R-U runs a "gbp build --git-builder=pbuilder" at the end and $gbp >> buildpackage cannot proceed without everything being committed. > I just cross-checked (and updated another two packages over it). It is > not two builds that it is doing, it is just a "gbp tag" after the first > (and only) build. And that build leaves newly created files that should > be cleaned by a "./debian/rules clean" on my system.
routine-update now checks if the repository is clean prior to invoking 'gbp tag', and runs ./debian/rules clean if not. I hope this is tolerable for you all, should have done that earlier. Steffen
