Bug#1052219: unrecognized option '--insert-timestamp=1686475264'
On 2023-09-19 Shengjing Zhu wrote: > On Tue, Sep 19, 2023 at 5:08 PM Andreas Metzler wrote: [...] > > 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 Thanks for the explanation. cu Andreas
Bug#1052219: unrecognized option '--insert-timestamp=1686475264'
On Tue, Sep 19, 2023 at 5:08 PM Andreas Metzler wrote: > > Control: tags 1052219 moreinfo > > On 2023-09-19 Shengjing Zhu wrote: > > On Tue, Sep 19, 2023 at 2:57 PM Shengjing Zhu 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
Bug#1052219: unrecognized option '--insert-timestamp=1686475264'
Control: tags 1052219 moreinfo On 2023-09-19 Shengjing Zhu wrote: > On Tue, Sep 19, 2023 at 2:57 PM Shengjing Zhu 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? Nicholas (as NMUer) - can you explain? cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#1052219: unrecognized option '--insert-timestamp=1686475264'
Control: reassign -1 src:libgcrypt20 1.10.2-2 Control: clone -1 -2 Control: reassign -2 src:gcc-mingw-w64 25.2 On Tue, Sep 19, 2023 at 2:57 PM Shengjing Zhu wrote: > > Package: binutils-mingw-w64-i686 > Version: 2.41-4+11+nmu1 > Severity: serious > Tags: ftbfs > X-Debbugs-Cc: ol...@debian.org, z...@debian.org > > 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. -- Shengjing Zhu
Bug#1052219: unrecognized option '--insert-timestamp=1686475264'
Package: binutils-mingw-w64-i686 Version: 2.41-4+11+nmu1 Severity: serious Tags: ftbfs X-Debbugs-Cc: ol...@debian.org, z...@debian.org 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.
