Your message dated Wed, 9 Sep 2026 03:37:22 +0200 with message-id <[email protected]> and subject line Re: Bug#1124669: dpkg-source -b can leave additional space when un-folding headers has caused the Debian Bug report #1124669, regarding dpkg-source -b can leave additional space when un-folding headers to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 1124669: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1124669 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: git-debpush Version: 14.1 Severity: normal Hi, I'm working on a service that compares the source packages in the archive to re-generated-from-git source packages. See https://debaudit-dev/git2dsc/ I ran into several uploads where the re-generated-from-git source package has a minor difference with the package in the archive regarding the Uploaders field. For example, take deepin-icon-theme 2025.12.04-1 https://debaudit.debian.net/git2dsc/result/1ddd74147e5eefd52543cc4902ce36685ca300702ab837fb49e92229d82a21ae The diff between the archive dsc and the rebuilt dsc is: --- /var/tmp/oc.7zuxkmuq/archive/deepin-icon-theme_2025.12.04-1_unsigned_stripped.dsc 2026-01-01 08:43:15.137814131 +0000 +++ /var/tmp/oc.7zuxkmuq/deepin-icon-theme_2025.12.04-1_stripped.dsc 2026-01-01 08:43:15.137814131 +0000 @@ -4,7 +4,7 @@ Architecture: all Version: 2025.12.04-1 Maintainer: Debian Deepin Packaging Team <[email protected]> -Uploaders: Yangfl <[email protected]>, Boyuan Yang <[email protected]>, Yanhao Mo <[email protected]>, Hu Feng <[email protected]>, +Uploaders: Yangfl <[email protected]>, Boyuan Yang <[email protected]>, Yanhao Mo <[email protected]>, Hu Feng <[email protected]>, Homepage: https://github.com/linuxdeepin/deepin-icon-theme Standards-Version: 4.7.3 Vcs-Browser: https://salsa.debian.org/pkg-deepin-team/deepin-icon-theme The source package is rebuilt with 'dpkg-buildpackage -S -us -uc -d -nc' which translates to 'dpkg-source -b .' With dpkg-dev 1.22.21 (trixie, forky) I get the added space. Of course that difference is irrelevant (it looks like it's gone in the Sources file generated by dak), but I would like to understand where it comes from, in order to understand how to best treat it on the debaudit side. Thanks, Lucas
--- End Message ---
--- Begin Message ---Version: 1.23.4 On Thu, 2026-01-08 at 10:43:22 +0100, Lucas Nussbaum wrote: > On 05/01/26 at 13:48 +0000, Ian Jackson wrote: > > Control: retitle -1 dpkg-source -b can leave additional space when > > un-folding headers > > Control: reassign -1 dpkg-dev > > Control: clone -1 -2 > > Control: retitle -2 should dgit build normaalise .dsc with > > Dpkg::Control::Hash? > > Control: severity -2 normal > > Control: block 932802 by -2 > > > > Lucas Nussbaum writes ("Bug#1124669: git-debpush does something strange > > with the Uploaders field"): > > > I ran into several uploads where the re-generated-from-git source > > > package has a minor difference with the package in the archive regarding > > > the Uploaders field. > > > > > > For example, take deepin-icon-theme 2025.12.04-1 > > > https://debaudit.debian.net/git2dsc/result/1ddd74147e5eefd52543cc4902ce36685ca300702ab837fb49e92229d82a21ae > > > > > > The diff between the archive dsc and the rebuilt dsc is: > > ... > > > Maintainer: Debian Deepin Packaging Team > > > <[email protected]> > > > -Uploaders: Yangfl <[email protected]>, Boyuan Yang <[email protected]>, > > > Yanhao Mo <[email protected]>, Hu Feng <[email protected]>, > > > +Uploaders: Yangfl <[email protected]>, Boyuan Yang <[email protected]>, > > > Yanhao Mo <[email protected]>, Hu Feng <[email protected]>, > > > > I investigated this. This package was indeed uploaded via tag2upload. > > But, this will affect any package with a similar debian/control > > uploaded via either dgit or tag2upload. > > > > The root causes are the following: > > > > 0. This package's git tree's debian/control haas an Uploaders field > > whose first line doesn't contain any Uploader. > > > > 1. dpkg-source -b emits an additional space when building the source > > package, presumably due to (0). > > > > 2. dgit and tag2upload need to insert the Dgit: field into the .dsc, > > to state precisely which git tree this came from. They use > > libdpkg-perl's Dpkg::Control::Hash for this. > > > > 3. libdpkg-perl's Dpkg::Control::Hash normalises the syntax, removing > > the additional space when the .dsc is re-output. > > > > I think there is nothing wrong with the package, so (0) should be > > considered normal. I think dgit is using a correct technique (indeed > > arguably the best technique) for its task, so (2) is correct. That > > Dpkg::Control::Hash normalises (3) is documented, so also IMO correct. > > > > I think (1) is suboptimal. dpkg-source -b makes an effort to unfold > > the lines, but its algorithm produces an anomalous output out of input > > that should be considered sensible. So I have reassigned this bug > > to dpkg-dev. > > > > > Of course that difference is irrelevant (it looks like it's gone in the > > > Sources file generated by dak), but I would like to understand where it > > > comes from, in order to understand how to best treat it on the debaudit > > > side. > > > > Thanks for the report. Indeed, it makes sense to understand this. > > > > >From my POV. it is rather unfortunate that this happens between "dgit > > build-source" and "dgit push-source". We might consider changing > > "dgit build-sourcd" to also put the .dsc through Dpkg::Control::Hash. > > I've cloned this bug for that. > > Thanks for the detailed investigation. > In debaudit's git2dsc checker, I added a pass through > Dpkg::Control::Hash to normalize both dscs, so this is no longer flagged > as a problem. I think this was fixed in dpkg 1.23.4. To make sure, I checked with a local package, and I cannot reproduce this anymore. Thus closing. Thanks, Guillem
--- End Message ---
