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