On Fri, 2025-09-05 at 21:26 -0400, Sergio Durigan Junior wrote: > So, the reason why GDB generates its source package this way is explained at > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950606 . > Long story short, these extra parameters are there to ensure that the final > tarball is reproducible. > > I'm Cc'ing Vagrant, who requested this change and provided the patch, so that > we can have a more informed conversation about what's happening here and > hopefully reach a solution.
Yes, I'd like Vagrant's input on this analysis, but I think there are two similar concepts being confused here with respect to timestamps. Debian Policy § 4.7 says, with respect to files in source packages at least, that: > Maintainers should preserve the modification times of the upstream source > files in a package, as far as is reasonably possible. gdb-source is a binary package, not a true source package in the dpkg sense, but this technicality shouldn't make a difference for this sentiment. Keeping upstream timestamps when building gdb-source shouldn't affect reproducibility because the timestamps would be the same unless you are changing upstream versions. I think the only timestamp-related issue here, aside from the fact that the debian/ directory and quilt's .pc/ directory for applied patches is packed in as well, is that any dh_autoreconf'ing or mangling of gdb/version.in that happens before gdb-source's tarball gets packed up, will cause the actual timestamps of those changes to end up in the tarball. See https://buildd.debian.org/status/fetch.php?pkg=gdb&arch=all&ver=17.0.50.20250905-1%7Eexp1&stamp=1757101822&raw=1 starting at line 1461 for what happens when building the gdb-source binary package; it could just be config.guess and config.sub getting poked that causes this. Right now gdb-source seems to have only four reverse build dependencies: • gcc-sh-elf (from yours truly, for SuperH bare-metal microcontrollers) • gdb-avr (for AVR bare-metal microcontrollers) • gdb-bpf (for Linux's eBPF facilities) • gdb-mingw-w64 (for Windows) These are all not your typical Debian targets and Debian-specific patches should generally not be applied to them at all, except for gfdl-dont-build-manpages.patch because that's a permanent downstream change, and perhaps others to help build across Debian hosts in a similar vein to swapping out config.guess and config.sub. As an outline, I think these steps would get things on the right track when building gdb-source: • Only apply the gfdl-dont-build-manpages patch to the upstream sources; ensure that other quilt-type patches are not applied. • Running autoreconf and/or replacing config.guess and config.sub, and retooling generally, is acceptable when care is taken to get the file attributes correct. • When assembling the tarball to be shipped in gdb-source, do not include the debian/ directory as it won't be needed by downstream users. • Do not include quilt's .pc/ directory; the tarball in gdb-source should appear to an observer to match the upstream sources, despite the minor change with respect to building documentation. The patch for that should never need to be unapplied. • For all changes made thus far, modification timestamps should be set to a fixed timestamp like DEB_TIMESTAMP is doing. Access timestamps and other file attributes should be discarded, except that read/write/execute permissions should be preserved, and the owning user/group can be set to root:root harmlessly. From there the build should be more deterministic. Keeping the name-based sorting argument to tar should be fine. And the POSIX tar format (known as "ustar") looks like it will support the attributes needed and this would be my preference for the sake of portability, but GNU-specific format is fine I suppose as long as only GNU-compatible tools are used to extract it: https://pubs.opengroup.org/onlinepubs/9799919799/utilities/pax.html#tag_20_94_13_06 P.S. The GDB source package seems to suggest, including in debian/copyright, debian/sanitize-gdb.sh, and the user-facing README.Debian, that the GNU Free Documentation License doesn't adhere to the DFSG. This is not true: the GFDL only runs afoul of the DFSG when the work has GFDL-sanctioned "invariant sections". Many GFDL works explicitly specify that there are no such supplemental invariant sections, and those works adhere to the DFSG. This decision is at https://www.debian.org/vote/2006/vote_001#outcome and particularly the second point of https://www.debian.org/vote/2006/vote_001#amendmenttexta P.P.S. The online documentation link in README.Debian to http://sourceware.org/gdb/onlinedocs/gdb.html is broken. This should be https://sourceware.org/gdb/documentation/ or something similar.
signature.asc
Description: This is a digitally signed message part
smime.p7s
Description: S/MIME cryptographic signature
