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

Groups > linux.debian.bugs.dist > #1270595 > unrolled thread

Bug#1120549: Reverting incorrect wiki changes

Back to article view | Back to linux.debian.bugs.dist

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

  Bug#1120549: Reverting incorrect wiki changes Soren Stoutner <soren@debian.org> - 2025-11-18 03:10 +0100
    Bug#1120549: Reverting incorrect wiki changes Johannes Schauer Marin Rodrigues <josch@debian.org> - 2025-11-18 09:20 +0100
      Bug#1120549: sbuild: unclear how to do a source-only build Soren Stoutner <soren@debian.org> - 2025-11-19 03:00 +0100
        Bug#1120549: sbuild: unclear how to do a source-only build Johannes Schauer Marin Rodrigues <josch@debian.org> - 2025-11-19 07:30 +0100
          Bug#1120549: sbuild: unclear how to do a source-only build Soren Stoutner <soren@debian.org> - 2025-11-19 18:20 +0100
            Bug#1120549: sbuild: unclear how to do a source-only build Johannes Schauer Marin Rodrigues <josch@debian.org> - 2025-11-20 02:30 +0100
              Bug#1120549: sbuild: unclear how to do a source-only build Soren Stoutner <soren@debian.org> - 2025-11-20 20:30 +0100
                Bug#1120549: sbuild: unclear how to do a source-only build Johannes Schauer Marin Rodrigues <josch@debian.org> - 2025-11-20 23:00 +0100
                  Bug#1120549: sbuild: unclear how to do a source-only build Soren Stoutner <soren@debian.org> - 2025-11-20 23:30 +0100
                    Bug#1120549: sbuild: unclear how to do a source-only build Johannes Schauer Marin Rodrigues <josch@debian.org> - 2025-11-21 00:50 +0100
                      Bug#1120549: sbuild: unclear how to do a source-only build Soren Stoutner <soren@debian.org> - 2025-11-22 05:10 +0100

#1270595 — Bug#1120549: Reverting incorrect wiki changes

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

I just needed to do a library transition, involving a binary upload to NEW.  
Without the $build_source entry in my .sbuildrc, it did not produce the 
necessary files.  When uploading the amd64.changes file, this is what was 
sent:

2025-11-17 18:22:22,746 - dput[80807]: uploader.invoke_dput - Uploading 
libsecp256k1 using ftp to ftp-master (host: ftp.upload.debian.org; directory: 
/pub/UploadQueue/)
2025-11-17 18:22:22,746 - dput[80807]: hook.run_hook - running allowed-
distribution: check whether a local profile permits uploads to the target 
distribution
2025-11-17 18:22:22,749 - dput[80807]: hook.run_hook - running protected-
distribution: warn before uploading to distributions where a special policy 
applies
2025-11-17 18:22:22,752 - dput[80807]: hook.run_hook - running checksum: 
verify checksums before uploading
2025-11-17 18:22:22,756 - dput[80807]: hook.run_hook - running suite-mismatch: 
check the target distribution for common errors
2025-11-17 18:22:22,758 - dput[80807]: hook.run_hook - running gpg: check 
GnuPG signatures before the upload
2025-11-17 18:22:23,268 - dput[80807]: uploader.invoke_dput - Uploading 
libsecp256k1-6-dbgsym_0.7.0-1_amd64.deb
2025-11-17 18:22:24,337 - dput[80807]: uploader.invoke_dput - Uploading 
libsecp256k1-6_0.7.0-1_amd64.deb
2025-11-17 18:22:25,385 - dput[80807]: uploader.invoke_dput - Uploading 
libsecp256k1-dev_0.7.0-1_amd64.deb
2025-11-17 18:22:26,806 - dput[80807]: uploader.invoke_dput - Uploading 
libsecp256k1_0.7.0-1_amd64.buildinfo
2025-11-17 18:22:27,317 - dput[80807]: uploader.invoke_dput - Uploading 
libsecp256k1_0.7.0-1_amd64.changes

Which was promptly rejected because it did not contain the source.

With the $build_source entry in my .sbuildrc, uploading the amd64.changes 
performed as expected:

2025-11-17 18:48:55,512 - dput[113547]: uploader.invoke_dput - Uploading 
libsecp256k1 using ftp to ftp-master (host: ftp.upload.debian.org; directory: 
/pub/UploadQueue/)
2025-11-17 18:48:55,513 - dput[113547]: hook.run_hook - running allowed-
distribution: check whether a local profile permits uploads to the target 
distribution
2025-11-17 18:48:55,515 - dput[113547]: hook.run_hook - running protected-
distribution: warn before uploading to distributions where a special policy 
applies
2025-11-17 18:48:55,518 - dput[113547]: hook.run_hook - running checksum: 
verify checksums before uploading
2025-11-17 18:48:55,523 - dput[113547]: hook.run_hook - running suite-
mismatch: check the target distribution for common errors
2025-11-17 18:48:55,525 - dput[113547]: hook.run_hook - running gpg: check 
GnuPG signatures before the upload
2025-11-17 18:48:56,101 - dput[113547]: uploader.invoke_dput - Uploading 
libsecp256k1_0.7.0-1.dsc
2025-11-17 18:48:56,631 - dput[113547]: uploader.invoke_dput - Uploading 
libsecp256k1_0.7.0.orig.tar.gz
2025-11-17 18:48:57,826 - dput[113547]: uploader.invoke_dput - Uploading 
libsecp256k1_0.7.0-1.debian.tar.xz
2025-11-17 18:48:58,365 - dput[113547]: uploader.invoke_dput - Uploading 
libsecp256k1-6-dbgsym_0.7.0-1_amd64.deb
2025-11-17 18:48:59,255 - dput[113547]: uploader.invoke_dput - Uploading 
libsecp256k1-6_0.7.0-1_amd64.deb
2025-11-17 18:49:00,338 - dput[113547]: uploader.invoke_dput - Uploading 
libsecp256k1-dev_0.7.0-1_amd64.deb
2025-11-17 18:49:01,432 - dput[113547]: uploader.invoke_dput - Uploading 
libsecp256k1_0.7.0-1_amd64.buildinfo
2025-11-17 18:49:01,953 - dput[113547]: uploader.invoke_dput - Uploading 
libsecp256k1_0.7.0-1_amd64.changes


As such, I am reverting the incorrect sbuild wiki change.

If you are missing the source.changes, you probably need to add the following 
to your .sbuildrc (currently documented in the wiki):

# Produce a .changes file suitable for a source-only upload; this is the same 
as passing `--source-only-changes` to sbuild.
$source_only_changes = 1;

-- 
Soren Stoutner
soren@debian.org

[toc] | [next] | [standalone]

#1270615

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

Hi Soren,

Quoting Soren Stoutner (2025-11-18 02:58:57)
> As such, I am reverting the incorrect sbuild wiki change.

that would be this revert:

https://wiki.debian.org/sbuild?action=diff&rev1=332&rev2=333

Which part of the information that you removed was incorrect?

> If you are missing the source.changes, you probably need to add the following
> to your .sbuildrc (currently documented in the wiki):
> 
> # Produce a .changes file suitable for a source-only upload; this is the same 
> as passing `--source-only-changes` to sbuild.
> $source_only_changes = 1;

Maybe you are confusing sbuild, the tool to build binary artifacts with a tool
to perform uploads of files to ftp.debian.org? I fear that what you expect is
for sbuild to gain knowledge about how packages are uploaded to Debian. It
already gained the --source-only-changes option as a convenience feature. If
you need to upload both the source and the binary artifacts, you can use the
mergechanges tool to create a .changes file which contains both. But I don't
think sbuild is the right tool to tell that what you want to do right now is an
upload to Debian of type XY and then produce exactly what is needed for that
upload. This is something you should be telling a tool which is intended for
uploads to Debian and then *that* tool can drive sbuild and merge the .changes
files in whatever way necessary. Such a tool already exists: dgit.

I would like for you to revert your revert or explain why you think that this
is incorrect information.

Thanks!

cheers, josch

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

#1270742 — Bug#1120549: sbuild: unclear how to do a source-only build

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

On Tuesday, November 18, 2025 1:12:22 AM Mountain Standard Time Johannes 
Schauer Marin Rodrigues wrote:
> I would like for you to revert your revert or explain why you think that 
this
> is incorrect information.

The information in the wiki has been specifically written so that the example 
.sbuildrc produces a source.changes file and a <BINARY>.changes file suitable 
for upload to Debian with each build.  This makes it so that a user can easily 
do either of the following without needing any extra commands.

$ gbp buildpackage
$ cd ..
$ debsign <PACKAGE>_source.changes
$ dput <PACKAGE>_source.changes

or

$ gbp buildpackage
$ cd ..
$ debsign <PACKAGE>_amd64.changes
$ dput <PACKAGE>_amd64.changes

Having a .sbuildrc that does this is desirable to many users, particularly new 
users.  In fact, this entire bug report exists because a user was uncertain 
how to generate a source.changes file.  Having instructions in the wiki that 
accomplish this goal by default is important.

I am unaware of any downsides to having sbuild always generate functional 
copies of both changes files.  If there are, please feel free to enlighten me.  
Otherwise, it is important that both of the following commands be included in 
the example .sbuildrc or one or both of the .changes files will either not be 
produced or not be produced correctly.


# Build the source in addition to the other requested build artifacts.  
Without this, <BINARY>.changes files will not include the upstream source in 
their list and will fail uploads to Debian if they are for a -1 revision that 
includes a new upstream release; this is the same as passing `-s` to sbuild.
$build_source = 1;

# Produce a source.changes file suitable for a source-only upload; this is the 
same as passing `--source-only-changes` to sbuild.
$source_only_changes = 1;


Of course, an individual user may prefer to not follow the example or to 
disable these commands to their liking.

-- 
Soren Stoutner
soren@debian.org

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

#1270756 — Bug#1120549: sbuild: unclear how to do a source-only build

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

Hi,

Quoting Soren Stoutner (2025-11-19 02:52:50)
> On Tuesday, November 18, 2025 1:12:22 AM Mountain Standard Time Johannes 
> Schauer Marin Rodrigues wrote:
> > I would like for you to revert your revert or explain why you think that 
> this
> > is incorrect information.
> 
> The information in the wiki has been specifically written so that the example 
> .sbuildrc produces a source.changes file and a <BINARY>.changes file suitable 
> for upload to Debian with each build.  This makes it so that a user can easily 
> do either of the following without needing any extra commands.
> 
> $ gbp buildpackage
> $ cd ..
> $ debsign <PACKAGE>_source.changes
> $ dput <PACKAGE>_source.changes
> 
> or
> 
> $ gbp buildpackage
> $ cd ..
> $ debsign <PACKAGE>_amd64.changes
> $ dput <PACKAGE>_amd64.changes
> 
> Having a .sbuildrc that does this is desirable to many users, particularly new 
> users.  In fact, this entire bug report exists because a user was uncertain 
> how to generate a source.changes file.  Having instructions in the wiki that
> accomplish this goal by default is important.

okay, so you want the .changes file. The --source argument gives you that but
it does more and it does undesirable things which are explained in the text
that you removed.

> I am unaware of any downsides to having sbuild always generate functional
> copies of both changes files. If there are, please feel free to enlighten me.

The problem is not generating the .changes files. That's also why the
convenience option --source-only-changes exists.

> Otherwise, it is important that both of the following commands be included in
> the example .sbuildrc or one or both of the .changes files will either not be
> produced or not be produced correctly.
> 
> # Build the source in addition to the other requested build artifacts.  
> Without this, <BINARY>.changes files will not include the upstream source in 
> their list and will fail uploads to Debian if they are for a -1 revision that 
> includes a new upstream release; this is the same as passing `-s` to sbuild.
> $build_source = 1;
> 
> # Produce a source.changes file suitable for a source-only upload; this is the 
> same as passing `--source-only-changes` to sbuild.
> $source_only_changes = 1;
> 
> Of course, an individual user may prefer to not follow the example or to
> disable these commands to their liking.

I think I understand your problem now. Your problem is, that you do not get a
*_$arch.changes file which includes references to the source package and adding
the --source option or $build_source=1 does this and that's why you recommend
adding it. Is that correct?

Thanks!

cheers, josch

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

#1270826 — Bug#1120549: sbuild: unclear how to do a source-only build

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

On Tuesday, November 18, 2025 11:27:56 PM Mountain Standard Time Johannes 
Schauer Marin Rodrigues wrote:
> okay, so you want the .changes file. The --source argument gives you that 
but
> it does more and it does undesirable things which are explained in the text
> that you removed.

I have been using this option for years and have not noticed any undesirable 
effects.  I have read over the text you refer to, and it does not make plain 
to me what problems including this option causes.  Could you please be more 
explicit about how this is problematic?

> The problem is not generating the .changes files. That's also why the
> convenience option --source-only-changes exists.

As noted below, this option by itself does not generate a correct 
amd64.changes file.

> I think I understand your problem now. Your problem is, that you do not get 
a
> *_$arch.changes file which includes references to the source package and
> adding the --source option or $build_source=1 does this and that's why you
> recommend adding it. Is that correct?

That is correct.  Properly generating complete source.changes and 
$arch.changes files is an important aspect of the example .sbuildrc on the 
wiki.

-- 
Soren Stoutner
soren@debian.org

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

#1270880 — Bug#1120549: sbuild: unclear how to do a source-only build

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

Hi,

Quoting Soren Stoutner (2025-11-19 18:13:27)
> On Tuesday, November 18, 2025 11:27:56 PM Mountain Standard Time Johannes 
> Schauer Marin Rodrigues wrote:
> > okay, so you want the .changes file. The --source argument gives you that 
> but
> > it does more and it does undesirable things which are explained in the text
> > that you removed.
> 
> I have been using this option for years and have not noticed any undesirable 
> effects.  I have read over the text you refer to, and it does not make plain 
> to me what problems including this option causes.  Could you please be more
> explicit about how this is problematic?

you will end up uploading something else than you told sbuild to build. sbuild
was building the dsc that got copied in (the one produced on the outside) but
what you are uploading is the dsc which sbuild produced. And secondly, you are
loosing your input as sbuild will overwrite it with the new build artifacts it
created.

In the future, sbuild could gain new transports of the build artifacts into the
clean chroot environment. For example, sbuild could bind-mount the unpacked
source directory from the outside into the chroot and build with an overlayfs.
Or, if building from git, sbuild could use a tarball created by "git archive"
to copy the source into the chroot and then rely on pristine-tar to re-create
the upstream tarball. But this is not done yet and instead, the dsc and the
files referenced by it are used as build input.

> > The problem is not generating the .changes files. That's also why the
> > convenience option --source-only-changes exists.
> As noted below, this option by itself does not generate a correct
> amd64.changes file.

I guess what is "correct" depends, no? ;) As far as dpkg is concerned, it is
being told to build binary artifacts from source (that's what sbuild is for)
and it will thus produce a binary-only changes file. Usually you are doing
uploads to the archive using source-only uploads and that's what the
--source-only-changes option is for. In some cases, you also want to upload
binaries (if the package has to go through NEW) but sbuild cannot know when
that is needed. I'd thus argue that only including binary artifacts in the
$arch.changes is correct and that the tool performing the uploads should have
the knowledge about what is supposed to be in the .changes file that you
upload, not the program which is used to produce binary artifacts in a clean
build environment.

> > I think I understand your problem now. Your problem is, that you do not get
> > a *_$arch.changes file which includes references to the source package and
> > adding the --source option or $build_source=1 does this and that's why you
> > recommend adding it. Is that correct?
> That is correct.  Properly generating complete source.changes and
> $arch.changes files is an important aspect of the example .sbuildrc on the
> wiki.

Would the $both_changes=1 option in your ~/.config/sbuild/config.pl do what you
want? Use the patch of this MR:
https://salsa.debian.org/debian/sbuild/-/merge_requests/211

Thanks!

cheers, josch

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

#1270977 — Bug#1120549: sbuild: unclear how to do a source-only build

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

On Wednesday, November 19, 2025 6:23:59 PM Mountain Standard Time Johannes 
Schauer Marin Rodrigues wrote:
> you will end up uploading something else than you told sbuild to build. 
sbuild
> was building the dsc that got copied in (the one produced on the outside) 
but
> what you are uploading is the dsc which sbuild produced. And secondly, you
> are loosing your input as sbuild will overwrite it with the new build
> artifacts it created.

In what was would the .dsc be different?  Shouldn’t they be generated with 
identical information both times?

> > > I think I understand your problem now. Your problem is, that you do not
> > > get
> > > a *_$arch.changes file which includes references to the source package 
and
> > > adding the --source option or $build_source=1 does this and that's why 
you
> > > recommend adding it. Is that correct?
> > 
> > That is correct.  Properly generating complete source.changes and
> > $arch.changes files is an important aspect of the example .sbuildrc on the
> > wiki.
> 
> Would the $both_changes=1 option in your ~/.config/sbuild/config.pl do what
> you want? Use the patch of this MR:
> https://salsa.debian.org/debian/sbuild/-/merge_requests/211

Yes, it looks like that patch would address all my concerns.

-- 
Soren Stoutner
soren@debian.org

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

#1270997 — Bug#1120549: sbuild: unclear how to do a source-only build

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

Hi,

Quoting Soren Stoutner (2025-11-20 20:26:20)
> On Wednesday, November 19, 2025 6:23:59 PM Mountain Standard Time Johannes 
> Schauer Marin Rodrigues wrote:
> > you will end up uploading something else than you told sbuild to build.
> > sbuild was building the dsc that got copied in (the one produced on the
> > outside) but what you are uploading is the dsc which sbuild produced. And
> > secondly, you are loosing your input as sbuild will overwrite it with the
> > new build artifacts it created.
> In what was would the .dsc be different?  Shouldn’t they be generated with
> identical information both times?

maybe. But if you think it should be like that, the reproducible-builds team
and the dpkg developers have discussed this topic at length and as of today
this is not what is happening. You can try this out yourself. First create the
upstream tarball from an unpacked source package using "dpkg-source -b ." (this
is what sbuild calls as a convenience feature when you run it from an unpacked
source directory) and move the upstream tarball somewhere else. Then run sbuild
with --source to create another upstream tarball. Then compare the two with
diffoscope and you will very likely see differences. These include, but are not
limited to:

  - the root directory of the tarball will reflect the name of the directory
    that your unpacked source was in. If you build from git, then your source
    directory will probably not include the source version. The unpacked source
    inside sbuild will.
  - different versions of the compressor will produce differently compressed
    files
  - different version of dpkg will create different source packages
  - if your packaging git contains debian/source/local-options then these
    options might affect your source tarball but since that file is not being
    put into the source package it will not affect the source package packed by
    sbuild

> > > > I think I understand your problem now. Your problem is, that you do not
> > > > get a *_$arch.changes file which includes references to the source
> > > > package and adding the --source option or $build_source=1 does this and
> > > > that's why you recommend adding it. Is that correct?
> > > That is correct.  Properly generating complete source.changes and
> > > $arch.changes files is an important aspect of the example .sbuildrc on
> > > the wiki.
> > Would the $both_changes=1 option in your ~/.config/sbuild/config.pl do what
> > you want? Use the patch of this MR:
> > https://salsa.debian.org/debian/sbuild/-/merge_requests/211
> 
> Yes, it looks like that patch would address all my concerns.

Okay.

This is yet another convenience option. As manphiz notes, dgit performs the
mergechanges step automatically. I am still of the opinion that this feature
does not belong into sbuild but into the tool which you use to upload your
package.

Thanks!

cheers, josch

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

#1271002 — Bug#1120549: sbuild: unclear how to do a source-only build

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

On Thursday, November 20, 2025 2:56:46 PM Mountain Standard Time Johannes 
Schauer Marin Rodrigues wrote:
> > In what way would the .dsc be different?  Shouldn’t they be generated with
> > identical information both times?
> 
> maybe. But if you think it should be like that, the reproducible-builds team
> and the dpkg developers have discussed this topic at length and as of today
> this is not what is happening. You can try this out yourself. First create 
the
> upstream tarball from an unpacked source package using "dpkg-source -b ."
> (this is what sbuild calls as a convenience feature when you run it from an
> unpacked source directory) and move the upstream tarball somewhere else. 
Then
> run sbuild with --source to create another upstream tarball. Then compare 
the
> two with diffoscope and you will very likely see differences. These include,
> but are not limited to:
> 
>   - the root directory of the tarball will reflect the name of the directory
>     that your unpacked source was in. If you build from git, then your 
source
>     directory will probably not include the source version. The unpacked
> source inside sbuild will.
>   - different versions of the compressor will produce differently compressed
>     files
>   - different version of dpkg will create different source packages
>   - if your packaging git contains debian/source/local-options then these
>     options might affect your source tarball but since that file is not 
being
>     put into the source package it will not affect the source package packed
> by sbuild

Reading over this description, it sounds like in some cases, probably when 
working directly with git upstreams, using this option repacks the upstream 
source tarball.

In my workflows, which are mostly based on gbp with pristine-tar (probably the 
most common current workflow in Debian), I can confirm that it does not repack 
the source tarball.  Perhaps that is why I have never had any problems with 
using this option.

I say this as someone who cares an awful lot about reproducible builds.

> > > Would the $both_changes=1 option in your ~/.config/sbuild/config.pl do
> > > what
> > > you want? Use the patch of this MR:
> > > https://salsa.debian.org/debian/sbuild/-/merge_requests/211
> > 
> > Yes, it looks like that patch would address all my concerns.
> 
> Okay.
> 
> This is yet another convenience option. As manphiz notes, dgit performs the
> mergechanges step automatically. I am still of the opinion that this feature
> does not belong into sbuild but into the tool which you use to upload your
> package.

Based on your comment, it appears that this option is not needed if using the 
dgit workflow, which is good to know.  But I would imagine that the majority 
of users are not currently using dgit (perhaps that will change in the 
future).  So, I appreciate your being willing to add this convenience option 
for the rest of us.

-- 
Soren Stoutner
soren@debian.org

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

#1271007 — Bug#1120549: sbuild: unclear how to do a source-only build

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

Hi,

Quoting Soren Stoutner (2025-11-20 23:22:09)
> > maybe. But if you think it should be like that, the reproducible-builds
> > team and the dpkg developers have discussed this topic at length and as of
> > today this is not what is happening. You can try this out yourself. First
> > create the upstream tarball from an unpacked source package using
> > "dpkg-source -b ." (this is what sbuild calls as a convenience feature when
> > you run it from an unpacked source directory) and move the upstream tarball
> > somewhere else. Then run sbuild with --source to create another upstream
> > tarball. Then compare the two with diffoscope and you will very likely see
> > differences. These include, but are not limited to:
> > 
> >   - the root directory of the tarball will reflect the name of the directory
> >     that your unpacked source was in. If you build from git, then your 
> >     source
> >     directory will probably not include the source version. The unpacked
> >     source inside sbuild will.
> >   - different versions of the compressor will produce differently compressed
> >     files
> >   - different version of dpkg will create different source packages
> >   - if your packaging git contains debian/source/local-options then these
> >     options might affect your source tarball but since that file is not 
> >     being
> >     put into the source package it will not affect the source package packed
> >     by sbuild
>
> Reading over this description, it sounds like in some cases, probably when 
> working directly with git upstreams, using this option repacks the upstream 
> source tarball.

I don't follow. If by "this option" you mean --source, then that option will
*always* repack the upstream tarball. But it will do so inside the build chroot
and inside there you do not have any packaging git.

> In my workflows, which are mostly based on gbp with pristine-tar (probably the 
> most common current workflow in Debian), I can confirm that it does not repack 
> the source tarball.  Perhaps that is why I have never had any problems with 
> using this option.

If you run sbuild via gbp then gbp will create a source tarball for you,
possibly from the pristine-tar branch. gbp will then run "sbuild" which will
call "dpkg-source -b ." which will re-create the source on the *outside*. If
you also have --source or $build_source=1, then dpkg-buildpackage will
re-generate the source *again* but *inside* the chroot. You said you can
confirm that it does not repack it but I just confirmed the opposite and the
upstream tarballs differ.

> > This is yet another convenience option. As manphiz notes, dgit performs the
> > mergechanges step automatically. I am still of the opinion that this feature
> > does not belong into sbuild but into the tool which you use to upload your
> > package.
> Based on your comment, it appears that this option is not needed if using the 
> dgit workflow, which is good to know.  But I would imagine that the majority 
> of users are not currently using dgit (perhaps that will change in the 
> future).  So, I appreciate your being willing to add this convenience option 
> for the rest of us.

dgit is just an example. I'm saying that this feature should be in whatever
program you use for uploading and not in sbuild, be it dgit or any other tool.
Maybe we even soon get "rid" of dgit because there is tag2upload now...

cheers, josch

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

#1271119 — Bug#1120549: sbuild: unclear how to do a source-only build

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

On Thursday, November 20, 2025 4:44:14 PM Mountain Standard Time Johannes 
Schauer Marin Rodrigues wrote:
> If you run sbuild via gbp then gbp will create a source tarball for you,
> possibly from the pristine-tar branch. gbp will then run "sbuild" which will
> call "dpkg-source -b ." which will re-create the source on the *outside*. If
> you also have --source or $build_source=1, then dpkg-buildpackage will
> re-generate the source *again* but *inside* the chroot. You said you can
> confirm that it does not repack it but I just confirmed the opposite and the
> upstream tarballs differ.

Somewhat what I am seeing is different that what you are describing.  Here is 
what I see with both the $build_source = 1 and $source_only_changes = 1.  
While I don’t dispute that it is doing something to rebuild the source 
*inside* the sbuild, it doesn’t modify the source *outside* the sbuild, and 
the resulting .dsc files are identical after two successive builds.  In other 
words, there might be situations where these options could cause problems with 
other workflows that I am not familiar with, but when using gbp I don’t yet 
understand how this option causes any problems (except for perhaps using a few 
extra CPU cycles).

I hope the following output is helpful in understanding what I see.

$ ls -la
total 20
drwxrwxr-x  5 soren soren 4096 Nov 21 20:30 .
drwxr-xr-x 12 soren soren 4096 Nov 12 20:19 ..
drwxrwxr-x  7 soren soren 4096 Jan 30  2025 privacybrowser
drwxrwxr-x 19 soren soren 4096 Jan 30  2025 Releases
drwxrwxr-x  2 soren soren 4096 Jun 26 10:10 Review


The parent directory is empty of files (only three directories) before the 
first build.


$ cd privacybrowser/

privacybrowser$ gbp buildpackage
gbp:info: Creating /home/soren/Debian/privacybrowser/
privacybrowser_0.8.orig.tar.xz
gbp:info: Performing the build
...


gbp generates the .orig.tar from pristine-tar.


privacybrowser$ cd ..

$ ls -la
total 12436
drwxrwxr-x  5 soren soren    4096 Nov 21 20:33 .
drwxr-xr-x 12 soren soren    4096 Nov 12 20:19 ..
drwxrwxr-x  7 soren soren    4096 Jan 30  2025 privacybrowser
-rw-r--r--  1 soren soren 1138560 Nov 21 20:34 
privacybrowser_0.8-2_amd64-2025-11-22T03:31:45Z.build
lrwxrwxrwx  1 soren soren      53 Nov 21 20:31 
privacybrowser_0.8-2_amd64.build -> 
privacybrowser_0.8-2_amd64-2025-11-22T03:31:45Z.build
-rw-r--r--  1 soren soren   20069 Nov 21 20:33 
privacybrowser_0.8-2_amd64.buildinfo
-rw-r--r--  1 soren soren    2115 Nov 21 20:33 
privacybrowser_0.8-2_amd64.changes
-rw-r--r--  1 soren soren 1899736 Nov 21 20:33 privacybrowser_0.8-2_amd64.deb
-rw-r--r--  1 soren soren   13804 Nov 21 20:33 
privacybrowser_0.8-2.debian.tar.xz
-rw-r--r--  1 soren soren    1581 Nov 21 20:33 privacybrowser_0.8-2.dsc
-rw-r--r--  1 soren soren    1427 Nov 21 20:33 
privacybrowser_0.8-2_source.changes
-rw-rw-r--  1 soren soren 1699756 Nov 21 20:31 privacybrowser_0.8.orig.tar.xz
-rw-rw-r--  1 soren soren     833 Nov 21 20:31 
privacybrowser_0.8.orig.tar.xz.asc
-rw-r--r--  1 soren soren 7921264 Nov 21 20:33 privacybrowser-
dbgsym_0.8-2_amd64.deb
drwxrwxr-x 19 soren soren    4096 Jan 30  2025 Releases
drwxrwxr-x  2 soren soren    4096 Jun 26 10:10 Review

$ cp privacybrowser_0.8-2.dsc privacybrowser_0.8-2.dsc.old


Here a copy of the dsc is made to compare it against the second build.


$ cd privacybrowser/

privacybrowser$ gbp buildpackage
gbp:info: Performing the build
...


gbp does not regenerate the .orig.tar because it already exists.


privacybrowser$ cd ..

$ ls -la
total 13552
drwxrwxr-x  5 soren soren    4096 Nov 21 20:37 .
drwxr-xr-x 12 soren soren    4096 Nov 12 20:19 ..
drwxrwxr-x  7 soren soren    4096 Jan 30  2025 privacybrowser
-rw-r--r--  1 soren soren 1138560 Nov 21 20:34 
privacybrowser_0.8-2_amd64-2025-11-22T03:31:45Z.build
-rw-r--r--  1 soren soren 1138553 Nov 21 20:39 
privacybrowser_0.8-2_amd64-2025-11-22T03:37:17Z.build
lrwxrwxrwx  1 soren soren      53 Nov 21 20:37 
privacybrowser_0.8-2_amd64.build -> 
privacybrowser_0.8-2_amd64-2025-11-22T03:37:17Z.build
-rw-r--r--  1 soren soren   20069 Nov 21 20:38 
privacybrowser_0.8-2_amd64.buildinfo
-rw-r--r--  1 soren soren    2115 Nov 21 20:38 
privacybrowser_0.8-2_amd64.changes
-rw-r--r--  1 soren soren 1899736 Nov 21 20:38 privacybrowser_0.8-2_amd64.deb
-rw-r--r--  1 soren soren   13804 Nov 21 20:38 
privacybrowser_0.8-2.debian.tar.xz
-rw-r--r--  1 soren soren    1581 Nov 21 20:38 privacybrowser_0.8-2.dsc
-rw-r--r--  1 soren soren    1581 Nov 21 20:35 privacybrowser_0.8-2.dsc.old
-rw-r--r--  1 soren soren    1427 Nov 21 20:38 
privacybrowser_0.8-2_source.changes
-rw-rw-r--  1 soren soren 1699756 Nov 21 20:31 privacybrowser_0.8.orig.tar.xz
-rw-rw-r--  1 soren soren     833 Nov 21 20:31 
privacybrowser_0.8.orig.tar.xz.asc
-rw-r--r--  1 soren soren 7921264 Nov 21 20:38 privacybrowser-
dbgsym_0.8-2_amd64.deb
drwxrwxr-x 19 soren soren    4096 Jan 30  2025 Releases
drwxrwxr-x  2 soren soren    4096 Jun 26 10:10 Review


Notice, at this point, that the timestamp on the .orig.tar.xz did not change, 
so it was not modified by the $build_source = 1 option.


$ diff -s privacybrowser_0.8-2.dsc privacybrowser_0.8-2.dsc.old
Files privacybrowser_0.8-2.dsc and privacybrowser_0.8-2.dsc.old are identical


I fell like somehow I am not understanding what your concerns are with 
'$build_source = 1'.  I assume that your concerns are valid, as you know much 
more about the internals of sbuild than I do.

In the end, my only concern is that, as I posted earlier, without this option 
the generated _amd64.changes fails to do an upload to the NEW queue because it 
is missing entries.  For some reason, when '$build_source = 1' is used, it 
does generate a complete _amd64.changes that can be used to upload to NEW.

-- 
Soren Stoutner
soren@debian.org

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web