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
signature.asc
Description: signature
