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

Re: routine-update builds twice, but does not clean after the first



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, <steffen_moeller@gmx.de
>> <mailto:steffen_moeller@gmx.de>> 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




Reply to: