Ok. I re-checked the patch and realized that I checked the only wrong module (the only one which is arch all and not any).
So my apologies for the fuzz and will apply the patch with the appropriate changes. But here my original reply too: I admit that I joined late to this conversation. But my complain is not about the time_t change. My complain is the contradiction between two thing: 1. https://wiki.debian.org/binNMU says that I should declar[e] dependency between an arch: all to an arch: any package: Depends: foo (>= ${source:Version}), foo (<< ${source:Version}.1~) 2. The bug report ask to depend on 'syslog-ng-core (= $${binary:Version})' This two is contradict and because syslog-ng complies with the binNMU request, I really reluctant to change that. Especially because in that case another ticket will be created in no-time to revert it. This is from the proposed changelog: + * Adjust shlibs for syslog-ng-core to use a strict versioned depends; + previously, modules used >=, << dependencies which did not account for + the possibility of ABI skew in a binNMU, which is exactly what happens + with the 64-bit time_t transition. And my question is again, is the rules really changed or we bend the rules just because of one transition? On Fri, 2024-04-05 at 15:15 +0200, Bernd Zeimetz wrote: > Hi Attila, > > On Fri, 2024-04-05 at 09:47 +0100, Attila Szalay wrote: > > Based on https://wiki.debian.org/NonMaintainerUpload, the binNMU > > should > > be careful > > I think you are confusing binNMUs and NMUs. > See https://wiki.debian.org/binNMU > > They are handled more or less automatic as soon as a rebuild is > needed > for a transition. > > You might want to read the bug report again, it basically says that > no > NMU will be uploaded, but you package will break if you don't apply > the > attached patch. And the binNMU that will most likely break it will > happen. > > The way how the time_t change happens was discussed for a *long* > time, > you are a bit late with complaints. > > > Bernd > >
