On Saturday, September 06 2025, John Scott wrote: > 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.
Thank you for the further investigation. > 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. Before I set out to solve this problem on GDB's side, I would like to know your and the other maintainers' opinions about my proposal to drop the gdb-source binary package altogether and let each reverse-dependency deal with obtaining GDB's tarball the way they see fit (using uscan's components, for example). I never liked the idea of repacking GDB's source code during build time, and this reproducibility issue is just one of the things that make the whole ordeal harder. This is something that has been on my TODO list for some time, and now that the topic has come to my attention I might as well do it. > 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 I do understand the GDFL vs. Debian issue, but thanks for pointing it out. You may have noticed that I have recently taken over the full maintenance of the package and am slowly working towards modernizing it and handling old cruft. Could you please file a bug against src:gdb so that I don't forget to address this point? > 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. Fixed, thanks. -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/
signature.asc
Description: PGP signature
