Re: Guidence regarding package testing and patching

Soren Stoutner <[email protected]> Fri, 05 Dec 2025 11:39:41 -0700
Newsgroups	gmane.linux.debian.devel.mentors,gmane.linux.debian.devel.python
Organization	Debian
Message-ID	<103823579.97WbxFKrFQ@soren-desktop>
On Friday, December 5, 2025 11:28:38 AM Mountain Standard Time Jai kadam 
wrote:
> On Fri, 5 Dec, 2025, 11:48 pm Soren Stoutner, <[email protected]> wrote:
> > Resending as I realized I had accidentally dropped the debian-python list.
> > 
> > On Friday, December 5, 2025 11:07:44 AM Mountain Standard Time you wrote:
> > > On Fri, 5 Dec, 2025, 10:59 pm Soren Stoutner, <[email protected]> wrote:
> > > > To add a bit more information about the behavior of "gbp push” and 
“git
> > > > push”
> > > > and when to use them and mix their uses:
> > > > 
> > > > 1.  The key to understanding this is that “gbp push” will push the
> > > > following
> > > > things:
> > > > 
> > > > a.  The pristine-tar branch (if in use).
> > > > b.  The upstream branch.
> > > > c.  Any new tags on the upstream branch.
> > > > d.  The debian branch, but only if the changelog does not target
> > > > UNRELEASED.
> > > > e.  Check for a new tag in the debian branch for the latest changelog
> > > > entry
> > > > and push it, but only if the changelog does not target UNRELEASED.
> > > > 
> > > > 2.  What we want to avoid is pushing a debian/X.Y-Z tag on the debian
> > > > branch
> > > > before X.Y-Z has actually been accepted into Debian.
> > > > 
> > > > 3.  The following workflow accomplishes this:
> > > > 
> > > > a.  gbp import-orig --uscan (this updates pristine-tar if used, the
> > > > upstream
> > > > branch, the debian branch, and creates a new upstream tag).
> > > > b.  dch  (adjust the changelog version number accordingly, but leave
> > 
> > the
> > 
> > > > target as UNRELEASED).
> > > > c.  gbp buildpackage (make sure the package builds).
> > > > d.  <Fix any problems>.
> > > > e.  gbp push (this pushes pristine-tar if in use, the upstream branch,
> > 
> > and
> > 
> > > > the
> > > > new upstream branch tag, but not the debian branch because the
> > 
> > changelog
> > 
> > > > targets UNRELEASED).
> > > > f.  git push (this pushes the debian branch).
> > > 
> > > Noted! :)
> > > 
> > > > 4.  When ready to release:
> > > > 
> > > > a.  dch -r (this changes the target from UNRELEASED to unstable, edit
> > 
> > to
> > 
> > > > experimental if desired).
> > > 
> > > This is same as dch --release rigth ? Si it also adds the commit 
messages
> > 
> > Yes, “dch -r” and “dch --release” are the same.
> > 
> > > b.  gbp buildpackage (build the package with the final changelog).
> > > 
> > > > c.  Upload the package.
> > > > d.  gbp tag (this creates the debian/X.Y-Z tag, typically one only 
does
> > > > this
> > > > after the package has been accepted into Debian).
> > > > e.  gbp push (this pushes the debian/X.Y-Z tag).
> > > 
> > > That is use gbp push only once at the very end , right?
> > 
> > No, you also use “gbp push” in step 3.e above.  Otherwise, you need to use
> > multiple git commands to do the same things, which would be to push the
> > pristine-tar branch (if in use), the upstream branch, and the upstream
> > tag.
> > If these things are not done at this step, other people who clone the
> > repository cannot build the changes you have just made.  When reviewing
> > packages that other people have submitted to mentors I do the following.
> > 
> > 1.  gbp clone (if I haven’t already cloned the repository).
> > 2.  gbp pull (this pulls all three branches and the tags, so that I can
> > review
> > the most recent changes).
> > 3.  gbp buildpackage.
> > 
> > If you don’t get step 3.e and 3.f right, "gbp buildpacakge" will fail for
> > me.
> 
> Oh i see cause debian-branch will have the previous version of code cause
> gbp never uploads it while in unreleased state and we only do dch -r when
> we get a green flag from a mentor or maintianer of the package which then
> sets it to unstable and then when we run gbp tag and gbp push all work is
> done.
> 
> Is my understanding rigth ?

Yes, you are correct.  If we skip “gbp push” at step 3.e, the repository will 
not have the latest version of the pristine-tar branch (if used), the upstream 
branch, and the upstream tag.  If we skip “git push” at step 3.f, the 
repository will not have the latest version of the debian branch.  That is why 
both are needed.

It is confusing and not necessarily obvious from the documentation.  But, once 
you understand things, it isn’t too difficult of a workflow to follow.

To round out this discussion, if you accidentally run “dch -r” before things 
are ready to release and then run “gbp push”, you will end up with a debian/
X.Y-Z tag in the repository that is not pointing to the code that actually was 
released.  To fix this, delete the local debian/X.Y-Z tag, then delete the 
same tag on Salsa, then regenerate the tag using “gbp tag”.  Then push the tag 
using either “gbp push” or “git push --tags” (I have done this enough times to 
know the process by memory).

-- 
Soren Stoutner
[email protected]
signature.asc (application/pgp-signature, 833 B)