Hello,

I'm trying to update the gcc-sh-elf package which uses a shared tree to build a whole toolchain, similar to what's described at https://gcc.gnu.org/simtest-howto.html but with some added complexity due to drift between versions of GCC, GDB, and Newlib. In my specific instance, the top-level include/dwarf2.h is a header shared by both GCC and GDB. GDB's copy appears to not have symbols GCC 15 needs.

In general GCC keeps the "master copies", but since we use tarballs on different release schedules in Debian, letting GCC's version always win in a conflict isn't the right way to solve this. What would be helpful, instead, is for me to use file timestamps to figure out which project has the newest version and use that when merging the trees together. However gdb-source doesn't preserve this: with your experimental upload from earlier today I get
	$ tar --utc -tf /usr/src/gdb.tar.xz gdb/include/dwarf2.h
	-rwxr-xr-x 0/0           16958 2025-09-05 01:47 gdb/include/dwarf2.h
so it looks like the timestamp gets mangled in the process of packaging. This seems to be done at:

debian/rules:396
tar cfJ $(CURDIR)/debian/gdb-source/usr/src/gdb.tar.xz \
--format=gnu \
--mode=755 \
--mtime="@$(DEB_TIMESTAMP)" --clamp-mtime \
--numeric-owner --owner=0 --group=0 \
--sort=name \
$(notdir $(builddir_source))

These parameters look overzealous and neither necessary nor appropriate.
 • Why enforce use of the GNU-specific tar format as opposed to leaving it at the default? The ustar and pax formats are standardized in POSIX and the former ought to be adequate, but the default should always be fine.
 • All files get the executable bit set with 'mode=755', even plain text ones.
 • It's not clear what the modification time-related options are supposed to accomplish here, but it's hurting my use case and I wonder how this affects reproducible builds.

The actual Debian source package keeps the timestamps and permissions intact—it's just when bundling the files up for gdb-source they get lost.

Once you understand how this got to be the way it is, can you restore the information in subsequent uploads? That will help a lot. Thanks

Hi John,

Yeah, I can how these options can be a problem for your use case.

They are actually necessary; more below.

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.

On a side note, I would personally like to get rid of the gdb-source
binary package.  I understand why it exists and all, but it's just a
hack that we do in order to save megabytes of space in the archive.
Either way, we're keeping it for the time being of course.

Thanks,

A timestamp does not necessarily give you the granularity you are
looking for. It could easily end up being the timestamp of whenever it
was built (e.g. a binary NMU with no source code changes), not when the
file was last updated. A git clone vs. updating an existing git
repository may end up with different timestamps, even with the exact
same top-level commit.  If you get a security update for an old version
that gets updated after the newest upstream version fixes, you may end
up with a newer date with an older copy of the file... etc.

There are so many ways timestamps can be modified; I do not think it
will reliably detect the "newest" copy for you...

With pax it is possible to set the necessary attributes to get a
reproducible result, but it is considerably more fiddly finicky work
than with the gnu tar format. I am not sure about ustar; the
Reproducible Builds project documentation suggests ustar might be a
viable option (if indeed it's limitations are acceptible):

https://reproducible-builds.org/docs/archives/

Setting the mode was to fix differences in umask in the build
environments, but indeed, it is arguably an overly broad hammer. There
may be ways to do that more elegantly, without specifying each and every
file's mode appropriately.

Does it actually cause ... problems with the source code?

Without the timestamp normalization, If you build the package now, and
you build it a week from now, or possibly even seconds from now, you get
a different result... because the build time of some files gets embedded
in the archive, resulting in different .tar archives.

If that is actually true, I welcome better fixes to the issue...

Admittedly, A few things have happened in the last five or so years that
the details are not fresh in my mind... this was not the only issue
making GDB unreproducible in Debian at the time, but it seems the other
issues have been fixed recently! Yay!

Well, with my reproducible builds hat on, that would be another way to
solve the problem! :)


live well,
  vagrant

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:
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.