On Friday, September 05 2025, John Scott wrote:

> Hello,

Hi John,

> 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))

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

> These parameters look overzealous and neither necessary nor appropriate.

They are actually necessary; more below.

>  • 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

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,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/

Attachment: signature.asc
Description: PGP signature

Reply via email to