Hi Roberto and others, On Fri, May 09, 2025 at 09:39:25PM -0400, Roberto C. Sanchez wrote: > Steps to reproduce: > > 1. configure backports repo > 2. install git-buildpackage: apt-get install git-buildpackage > 3. install sbuild: apt-get install -t bookworm-backports sbuild > 4. create an appropriate sbuild environment: > mkdir -p ~/.cache/sbuild > mmdebstrap --verbose --mode=unshare --architecture="$(dpkg > --print-architecture)" --variant=apt > --hook-dir=/usr/share/mmdebstrap/hooks/maybe-merged-usr bookworm > ~/.cache/sbuild/bookworm-$(dpkg --print-architecture).tar.zst > /etc/apt/sources.list > /bin/echo -e '$chroot_mode="unshare";\n$clean_source=0;\n1;' > ~/.sbuildrc > 4. clone an arbitrary package from Salsa: git clone > https://salsa.debian.org/debian/krb5 > 5. Execute the build: > cd krb5 > git branch upstream origin/upstream > git branch pristine-tar origin/pristine-tar > git checkout -b bookworm origin/bookworm > gbp buildpackage --git-builder='sbuild -d bookworm --no-run-lintian > --source-only-changes' --git-debian-branch=bookworm > 6. Observe the presence of the buildinfo in the resulting source.changes: > grep buildinfo ../*_source.changes
It seems that the bug report consensus is that you see the inclusion of the .buildinfo file in the _source.changes as a bug. What you see as a bug, I see as a feature. I may perform a source-only upload and still convey that I reproducibly built the package. Can you or someone else elaborate on why you see the inclusion of the .buildinfo file as a problem? If there was some functional change removing the .buildinfo from a source upload, I'd be inclined to report the reverse bug in the absence of such reasoning. On the flip side, the inclusion of the buildinfo does pose downstream problems. We may now be faced with multiple .buildinfo files with the same filename and different content. As such, we may not just store them next to each other, but that's how mergechanges and reprepro operate leading to problems in their use and Debusine also encountered the issue with mergechanges on its own. Originally, reproducible builds would include a granular timestamp in the filename and you may see evidence for that in e.g. https://wiki.debian.org/ReproducibleBuilds/BuildinfoFiles#Example. That timestamp was replace with package_version_architecture in the dpkg implementation. Depending on why others see the inclusion of a binary .buildinfo as a problem, maybe using an unreproducible name would solve some of those problems? I note that we may influence the default filename: dpkg-genbuildinfo -O../othername.buildinfo dpkg-buildpackage --buildinfo-file=../othername.buildinfo sbuild --debbuildopt=--buildinfo-file=../othername.buildinfo In principle, sbuild could decide to choose a default that differs from dpkg's. Not sure we want that. In asked Guillem for references to the choice in filenames and he kindly provided * https://lists.debian.org/debian-dpkg/2016/11/msg00056.html Guillem argues that it would be difficult discovering the right buildinfo file and that there could be several of them from earlier builds. * https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/?id=d5005e4576bcf9b341e83cfb8647d5f96438642f The commit argues that there is no point in using unique filename. We now do have reasons to choose unique buildinfo filenames (i.e. there exist tools that assume them to be unique). For now, I'd like to understand why the inclusion of the buildinfo is seen as a problem and how others see the idea of changing the buildinfo filename as a means to avoid collisions. Helmut
