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 [email protected]
signature.asc
Description: This is a digitally signed message part.
