Bug#1052219: unrecognized option '--insert-timestamp=1686475264'

[Shengjing Zhu]

On Tue, Sep 19, 2023 at 5:08 PM Andreas Metzler <ametzler at bebt.de> wrote:
>
> Control: tags 1052219 moreinfo
>
> On 2023-09-19 Shengjing Zhu <zhsj at debian.org> wrote:
> > On Tue, Sep 19, 2023 at 2:57 PM Shengjing Zhu <zhsj at 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