Bug#1059535: transition: abseil
On 2024-04-01 10:39:08 -0400, Benjamin Barenblat wrote: > On Monday, April 1, 2024, at 2:57 PM +0200, Sebastian Ramacher wrote: > > Could you please re-add the build dependency on dpkg-dev (>= 1.22.5) to > > ensure that the build with the new armel/armhf ABI only migrates when > > the time_t transition is ready to advance? > > Yes! I am going to wait for the current upload (20230802.1-3) to finish > building on RISC-V, just to make sure the FTBFS is fixed. (It’s already > 11 hours in; it can’t take too much longer.) Once that’s done, I’ll > upload a new 20230802.1-4 with a Build-Depends: dpkg-dev (>= 1.22.5). > (If you’d prefer that I preempt the current build and upload > 20230802.1-4 right now, just let me know.) Sounds good. Let's wait for -3 to finish building on riscv64. Cheers -- Sebastian Ramacher
Bug#1059535: transition: abseil
On Monday, April 1, 2024, at 2:57 PM +0200, Sebastian Ramacher wrote: > Could you please re-add the build dependency on dpkg-dev (>= 1.22.5) to > ensure that the build with the new armel/armhf ABI only migrates when > the time_t transition is ready to advance? Yes! I am going to wait for the current upload (20230802.1-3) to finish building on RISC-V, just to make sure the FTBFS is fixed. (It’s already 11 hours in; it can’t take too much longer.) Once that’s done, I’ll upload a new 20230802.1-4 with a Build-Depends: dpkg-dev (>= 1.22.5). (If you’d prefer that I preempt the current build and upload 20230802.1-4 right now, just let me know.)
Bug#1059535: transition: abseil
On 2024-03-29 17:27:58 -0400, Benjamin Barenblat wrote: > On Friday, March 29, 2024, at 1:02 PM +0100, Sebastian Ramacher wrote: > > Since the version in unstable fails to build on armel and armhf and > > blocks the time_t transition, but the version in experimental builds > > fine, let's do this transition now. > > > > With the upload to unstable, please check the FTBFS issue on risc64, > > though. > > Sounds good. I never did get around to uploading 20240116 to > experimental. I’ll upload 20230802 to unstable this weekend, and I’ll > come back for 20240116 later. Thanks! Could you please re-add the build dependency on dpkg-dev (>= 1.22.5) to ensure that the build with the new armel/armhf ABI only migrates when the time_t transition is ready to advance? Cheers -- Sebastian Ramacher
Bug#1059535: transition: abseil
On Friday, March 29, 2024, at 1:02 PM +0100, Sebastian Ramacher wrote: > Since the version in unstable fails to build on armel and armhf and > blocks the time_t transition, but the version in experimental builds > fine, let's do this transition now. > > With the upload to unstable, please check the FTBFS issue on risc64, > though. Sounds good. I never did get around to uploading 20240116 to experimental. I’ll upload 20230802 to unstable this weekend, and I’ll come back for 20240116 later. Upstream has accepted [1], which should fix the FTBFS on riscv64. It should be an easy backport to 20230802. I’ll make sure it’s included when I do the upload this weekend. [1] https://github.com/abseil/abseil-cpp/commit/7335a36d0b5c1c597566f9aa3f458a5b6817c3b4
Bug#1059535: transition: abseil
Control: tags -1 confirmed Hi Benjamin On 2024-02-14 21:01:40 +0100, Sebastian Ramacher wrote: > On 2024-02-14 14:48:49 -0500, Benjamin Barenblat wrote: > > I’d like to alter this transition request. Instead of transitioning to > > version 20230802, I’d like to transition to version 20240116, which > > upstream recently released. > > > > Is that okay? If so, I’ll upload 20240116 to experimental and reexamine > > reverse dependencies. If not, please let me know how to proceed; a > > 20230802 -> 20240116 upgrade would require a second transition, and I > > don’t want to create extra work. > > That's okay. There is enough time to prepare a tranistion to 20240116 > until we have finished the time_t transition. Since the version in unstable fails to build on armel and armhf and blocks the time_t transition, but the version in experimental builds fine, let's do this transition now. With the upload to unstable, please check the FTBFS issue on risc64, though. See https://buildd.debian.org/status/fetch.php?pkg=abseil=riscv64=20230802.1-2=1703403912=0 Cheers -- Sebastian Ramacher
Processed: Re: Bug#1059535: transition: abseil
Processing control commands: > tags -1 confirmed Bug #1059535 [release.debian.org] transition: abseil Added tag(s) confirmed. -- 1059535: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059535 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1059535: transition: abseil
On 2024-02-14 14:48:49 -0500, Benjamin Barenblat wrote: > I’d like to alter this transition request. Instead of transitioning to > version 20230802, I’d like to transition to version 20240116, which > upstream recently released. > > Is that okay? If so, I’ll upload 20240116 to experimental and reexamine > reverse dependencies. If not, please let me know how to proceed; a > 20230802 -> 20240116 upgrade would require a second transition, and I > don’t want to create extra work. That's okay. There is enough time to prepare a tranistion to 20240116 until we have finished the time_t transition. Cheers -- Sebastian Ramacher
Bug#1059535: transition: abseil
I’d like to alter this transition request. Instead of transitioning to version 20230802, I’d like to transition to version 20240116, which upstream recently released. Is that okay? If so, I’ll upload 20240116 to experimental and reexamine reverse dependencies. If not, please let me know how to proceed; a 20230802 -> 20240116 upgrade would require a second transition, and I don’t want to create extra work.
Bug#1059535: transition: abseil
Hi, Am 27.12.23 um 19:15 schrieb Benjamin Barenblat: Although doing a transition now will break some packages in sid, I believe waiting is likely to cause more issues. Upstreams (LibreOffice in particular) are starting to use features from the new version of Abseil, Actually it's not LibreOffice but LibreOffice indirectly via pdfium (which makes chromium also be affected if it did build without using the embedded copy of abseil). That said libreoffice builds (both sids and experimentals version). Tested on amd64 only, but Regards, Rene
Bug#1059535: transition: abseil
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: abs...@packages.debian.org, Rene Engelhard Control: affects -1 + src:abseil Abseil 20230802 has been out for a while, and I'd like to transition sid to it. The new version has a new ABI (with a new SONAME and new binary package names). Tests for 20230802.1-2 in experimental are green on all supported architectures except mips64el and riscv64. mips64el had no installable libc when the builders ran; I expect it'll be fine when the transition actually happens. Large parts of Abseil (including the version already in sid) are broken on riscv64 right now because of https://bugs.debian.org/1059532; transitioning doesn't introduce any new issues. A number of packages in sid depend directly on Abseil. To give early warning of breakages, I've done trial rebuilds as appropriate on the amd64 porterbox. Packages that work fine with the new version: - grpc - libgav1 - libphonenumber - mujoco - open-vm-tools - ycmd Packages that are broken by the new version: - mozc: FTBFS because it depends on a symbol in the absl::internal namespace that changed without warning - re2: FTBFS because it needs changes to some symbols files - s2geometry: FTBFS because it hard-codes std=c+11 and the new version requires -std=c++14 or later (https://bugs.debian.org/1059228) - webrtc-audio-processing: FTBFS because it relies on transitive #includes that have changed Packages that I'm not sure about: - dm-tree: has an active FTBFS (https://bugs.debian.org/1055686) - ortools: has an active FTBFS (https://bugs.debian.org/1024790) - libreoffice: too big to build on a porterbox, so left untested Although doing a transition now will break some packages in sid, I believe waiting is likely to cause more issues. Upstreams (LibreOffice in particular) are starting to use features from the new version of Abseil, and keeping the old version in sid is starting to create work for other DDs. The breakages in sid will have to be fixed eventually anyway, and none of them should be challenging to repair. Ben file: title = "abseil"; is_affected = .depends ~ /\blibabsl20220623\b/ | .depends ~ /\blibabsl20230802\b/; is_good = .depends ~ /\blibabsl20230802\b/; is_bad = .depends ~ /\blibabsl20220623\b/;
