Hi Dennis, On Thu, Feb 08, 2024 at 06:36:24PM +0100, Dennis Filder wrote: > X-Debbugs-CC: Steve Langasek <vor...@debian.org>
> The packages bctoolbox, belle-sip and linphone have been marked as > affected by the 64-bit time_t transition. However, all these packages > currently have new versions staged in experimental because their > library packages had soname bumps unrelated to the 64-bit time_t > transition (which you already noticed for belle-sip). As long as > these staged versions actually make it into testing before the Trixie > freeze there should be no need for these NMU diffs, correct? There is perhaps no need for you to apply these diffs to your package; and for any of these packages where you will be changing sonames, the diffs can be dropped. But without making this transition explict in unstable, *any* no-change rebuild in the meantime, of any of these libraries or their reverse-dependencies, would result in potentially RC-buggy ABI skew. So our intent would still be to NMU these to unstable even if the library transition is subsequently superseded. > > Since turning on 64-bit time_t is being handled centrally through a change > > to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is > > important that libraries affected by this ABI change all be uploaded close > > together in time. > I presume the need for "close together in time" is to prevent > interoperability issues from cropping up in unstable between shared > library versions on different sides of the time_t transition. How > timely would our staged versions need to be uploaded to unstable to > obviate the need for the NMUs? I ask because it is very difficult to > say with a useful degree of certainty when these staged versions will > actually reach testing. Experience has shown that linphone stack > transitions are prone to being afflicted by (sometimes multi-month) > delays due to being blocked by other transitions, and I see no open > bugreport for linphone on the release.debian.org pseudopackage, so > Berni (who will do these uploads) apparently has not yet applied for a > new transition slot. Based on the above I think you should let us go ahead with the NMUs to unstable and not worry about it, clobbering them later at your convenience. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
