Package: gdb-source Version: 16.3-1 Severity: normal Control: affects -1 src:gcc-sh-elf Control: found -1 17.0.50.20250905-1~exp1
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
signature.asc
Description: This is a digitally signed message part
smime.p7s
Description: S/MIME cryptographic signature
