Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #17241 > unrolled thread

Re: Guidence regarding package testing and patching

Back to article view | Back to linux.debian.maint.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Guidence regarding package testing and patching Jai kadam <jaivkadam@gmail.com> - 2025-12-05 19:10 +0100
    Re: Guidence regarding package testing and patching Soren Stoutner <soren@debian.org> - 2025-12-05 19:20 +0100
      Re: Guidence regarding package testing and patching Jai kadam <jaivkadam@gmail.com> - 2025-12-05 19:30 +0100
        Re: Guidence regarding package testing and patching Soren Stoutner <soren@debian.org> - 2025-12-05 19:50 +0100

#17241 — Re: Guidence regarding package testing and patching

[Multipart message — attachments visible in raw view] — view raw

On Fri, 5 Dec, 2025, 10:59 pm Soren Stoutner, <soren@debian.org> wrote:

> On Thursday, December 4, 2025 12:45:30 PM Mountain Standard Time Andrey
> Rakhmatullin wrote:
> > On Fri, Dec 05, 2025 at 01:12:14AM +0530, Jai kadam wrote:
> > >> >> You can also consult its manpage to learn what does it do.
> > >> >
> > >> >I see, I read the man page just now after your suggestion it's not
> > >>
> > >> detailed.
> > >>
> > >> It's very detailed
> > >
> > >By manual you mean "man gbp" or something else?
> >
> > I mean gbp-push(1), you could learn that it exists from "SEE ALSO" of
> > gbp(1).
>
> 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

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?

>
> Note that it is possible to do all of this using a plethora of git
> commands.
> gbp simply makes it easier.
>
> On a side note, "gbp clone” is just like “git clone” except that it
> automatically clones the pristine-tar branch (if used), the upstream
> branch,
> and the debian branch, whereas “git clone” just clones the default branch
> and
> requires extra commands to populate the other ones.
>
> --
> Soren Stoutner
> soren@debian.org

Thank you!

[toc] | [next] | [standalone]

#17242

[Multipart message — attachments visible in raw view] — view raw

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, <soren@debian.org> wrote:
> > On Thursday, December 4, 2025 12:45:30 PM Mountain Standard Time Andrey
> > 
> > Rakhmatullin wrote:
> > > On Fri, Dec 05, 2025 at 01:12:14AM +0530, Jai kadam wrote:
> > > >> >> You can also consult its manpage to learn what does it do.
> > > >> >
> > > >> >I see, I read the man page just now after your suggestion it's not
> > > >> 
> > > >> detailed.
> > > >> 
> > > >> It's very detailed
> > > >
> > > >By manual you mean "man gbp" or something else?
> > > 
> > > I mean gbp-push(1), you could learn that it exists from "SEE ALSO" of
> > > gbp(1).
> > 
> > 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.

-- 
Soren Stoutner
soren@debian.org

[toc] | [prev] | [next] | [standalone]

#17243

[Multipart message — attachments visible in raw view] — view raw

On Fri, 5 Dec, 2025, 11:48 pm Soren Stoutner, <soren@debian.org> 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, <soren@debian.org> wrote:
> > > On Thursday, December 4, 2025 12:45:30 PM Mountain Standard Time Andrey
> > >
> > > Rakhmatullin wrote:
> > > > On Fri, Dec 05, 2025 at 01:12:14AM +0530, Jai kadam wrote:
> > > > >> >> You can also consult its manpage to learn what does it do.
> > > > >> >
> > > > >> >I see, I read the man page just now after your suggestion it's
> not
> > > > >>
> > > > >> detailed.
> > > > >>
> > > > >> It's very detailed
> > > > >
> > > > >By manual you mean "man gbp" or something else?
> > > >
> > > > I mean gbp-push(1), you could learn that it exists from "SEE ALSO" of
> > > > gbp(1).
> > >
> > > 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 ?

> --
> Soren Stoutner
> soren@debian.org
>

[toc] | [prev] | [next] | [standalone]

#17244

[Multipart message — attachments visible in raw view] — view raw

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, <soren@debian.org> 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, <soren@debian.org> 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
soren@debian.org

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web