On Tue, Sep 19, 2023 at 5:08 PM Andreas Metzler <ametz...@bebt.de> wrote: > > Control: tags 1052219 moreinfo > > On 2023-09-19 Shengjing Zhu <z...@debian.org> wrote: > > On Tue, Sep 19, 2023 at 2:57 PM Shengjing Zhu <z...@debian.org> wrote: > > > Package: binutils-mingw-w64-i686 > > > Version: 2.41-4+11+nmu1 > [...] > >> The NMU binutils-mingw-w64/11+nmu1 drops specify-timestamp.patch. > >> It causes libgcrypt20, gcc-mingw-w64 FTBFS. > >> > >> These packages use options like --insert-timestamp=1686475264, > >> which is not supported in upstream implementation. > >> > >> I find such option is mentioned on > >> https://wiki.debian.org/ReproducibleBuilds/TimestampsInPEBinaries > >> It looks like Debian specific behaviour. > > > Asking libgcrypt20 and gcc-mingw-w64 to stop using this option makes more > > sense. > > > Looking at the changelog entry > * Drop specify-timestamp.patch, applied upstream in binutils 2.41 > (Closes: #1042734) > changing the rdeps does not make any sense at all, since the > --insert-timestamp support is now supposed to be available upstream? > Since binutils-mingw-w64-i686 is reported to be 2.41 the support should > be available. So is binutils-mingw-w64-i686 actually 2.41 and if yes, > why does "applied upstream" not hold?
Upstream implements it in a different way, it doesn't take argument in --insert-timestamp option, it just looks SOURCE_DATE_EPOCH implicitly. Ref https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=6badd1020f5bebd3f60a780b8e41a1b581046087 > > Nicholas (as NMUer) - can you explain? > -- Shengjing Zhu
