NOTICE: these changes must not be uploaded to unstable yet! Dear maintainer, As part of the 64-bit time_t transition required to support 32-bit architectures in 2038 and beyond (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified samba as a source package shipping runtime libraries whose ABI either is affected by the change in size of time_t, or could not be analyzed via abi-compliance-checker (and therefore to be on the safe side we assume is affected). To ensure that inconsistent combinations of libraries with their reverse-dependencies are never installed together, it is necessary to have a library transition, which is most easily done by renaming the runtime library package. 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. Therefore I have prepared a 0-day NMU for samba which will initially be uploaded to experimental if possible, then to unstable after packages have cleared binary NEW. Please find the patch for this NMU attached. This NMU has not been uploaded to experimental yet because it is waiting on an update of the binary package override database from the ftp team for libsmbclient, which was late identified as a package name requiring special handling. If you have any concerns about this patch, please reach out ASAP. There will be a period of several days before we begin uploads to unstable; so if information becomes available that your package should not be included in the transition, there is time for us to amend the planned uploads.
20.02.2024 09:30, Steve Langasek wrote:
One more note: samba package in experimental is *not* yet intended for unstable, it is a pre-release of next samba version and I don't plan to upload it to unstable yet. If any work is needed, it should be done on top of 4.19. But I'm not sure how to coordinate it all yet. At the very least, I'm willing to help, can prepare things with 4.19 and upload when needed. /mjt
Kia Ora Steve, So long since we had a chance to work together, and I thank you for your work on Debian. Can we have a chat about this? sssd does not, as I read it, use any time_t relevant parts of ldb, and is the only external user of LDB in Debian that we know of. Also, the debdiff changes the description of libsmbclient to libsmbclient0 unintentionally in the free text. I think therefore with some care we can reduce the impact of this significantly, down to libsmbclient, which seems to use struct timespec. Andrew Bartlett -- Andrew Bartlett (he/him) https://samba.org/~abartlet/Samba Team Member (since 2001) https://samba.orgSamba Team Lead https://catalyst.net.nz/services/sambaCatalyst.Net Ltd Proudly developing Samba for Catalyst.Net Ltd - a Catalyst IT group company Samba Development and Support: https://catalyst.net.nz/services/samba Catalyst IT - Expert Open Source Solutions
Very much agreed :-) I checked the header, and there are a lot of references to "struct timespec" in the main structures, plus one of time_t in a printing thing. Andrew Bartlett
20.02.2024 10:30, Andrew Bartlett : It is not only about Debian. The transition is here not just for packages in Debian, but also for any external 3rd-paty packages which might be installed on user systems from any external sources or built locally. Still, libldb and samba-libs are private-to-samba things (or at least semi-private), libldb isn't something which is consumed externally (even sssd *extends* libldb, not "uses" it). There should be no external consumers of it. And for sssd, we had enough changes in libldb already which breaks sssd in one way or another and needs sssd rebuild or refinement. FWIW. Do we really need libldb package? Maybe it can be a part of samba-libs? There's a thread about that on samba-technical@, but it occured to me only now, - do we *really* need a separate libldb? I'll reply on samba-technical@, this has nothing to do with this time_t transition. /mjt
I have prepared another patch on top of what is in experimental now (attached as nmu_samba.debdiff), does it look better? I have also prepared a patch on top of what is currently in unstable, attached as nmu_samba_unstable.debdiff. I think the ideal way forward would be to upload to experimental asap to check it builds and to let Helmut run dumat on it and then upload the unstable patch when the transition starts in earnest (planned for Friday this week). The changes are pretty orthogonal to the differences between what is unstable and experimental currently afaict. Cheers, mwh
21.02.2024 11:26, Michael Hudson-Doyle wrote: It's named nmu_samba_STABLE.debdiff, though - made me confused for a bit :) Yes, this is exactly what I had in mind, and already prepared the very same changes locally in the package git repository. Yes, that's what I was thinking about, too. Still, I prefer to have 4.19 in unstable so far, not 4.20-rc. So we can either do an NMU of 4.19, based on your nmu_samba_UNstable.debdiff, or I can do a regular upload once the transition starts. Uploading what I have for experimental now, which is essentially the same as your nmu_samba.debdiff. Thanks, /mjt
Oops, sorry about that! That makes sense. We definitely do not want to have to coordinate with other transitions for this, so it sounds like we (or maybe you!) should just patch the 4.19 in unstable and then you can migrate 4.20 when it suits you. So we can either do an NMU of 4.19, based on your In some sense it would be easiest to just NMU samba like we are planning to with everything else but I don't have a strong feeling about this. Thanks!
21.02.2024 12:03, Michael Hudson-Doyle wrote: ... I just uploaded a new release to experimental. Here are the 2 commits: https://salsa.debian.org/samba-team/samba/-/commits/debian/2%254.20.0_rc2+dfsg-3 which makes the t64 changes (note the X-Time64-Compat header, too). Exactly the same changes applies on top of 4.19 currently in unstable. I especially split it into two commits, one actual change and one d/changelog, so the two can be applied separately, - since obviously d/changelog changes wont apply cleanly and needs manual edit. Yeah, - can be done either way, that's why I'm making it easier. Thanks, /mjt