Re: Heads-up: abseil-cpp 20250814.0 coming to F44/Rawhide and F43

Ben Beasley <code@xxxxxxxxxxxxxxxxxx> · Thu, 11 Sep 2025 12:57:17 +0100



    Abseil LTS 20250814.0 has landed in F44/Rawhide[1].
    I already conducted nearly all of the builds for the
      corresponding F43 update in side tag f43-build-side-118508, but I
      ran into a conflict with a Qt side tag, affecting the qt6-qtgrpc
      package. It looks like I will need to keep my abseil-cpp side tag
      open until the F43 beta freeze ends and the Qt update[2] reaches
      stable. If you maintain one of the dependent packages listed in
      the original email and you need to update your package in F43
      before then, please coordinate with me or build directly into the
      side tag. I am also aware that this side tag may interact with the
      Python mini-mass-rebuild planned after the beta freeze.

    
    [1]
      https://bodhi.fedoraproject.org/updates/FEDORA-2025-8ab19b6dfe
    [2]
      https://bodhi.fedoraproject.org/updates/FEDORA-2025-cca3b373bd

    
    On 01/09/2025 9:26 am, Ben Beasley
      wrote:

    
      In one week, 2025-09-08, or slightly later, I
        plan to update abseil-cpp from 20250512.1 to 20250814.0 (Abseil
        LTS branch, August 2025)[1] in a side tag for F44/Rawhide. I
        plan to do the same update for F43/Branched as well, but I
        intend to wait until the Beta Freeze is over in order to
        minimize the time the side tag is open and therefore the risk of
        conflicts with other updates.
      

      Like all new calendar versions of abseil-cpp,
        this breaks ABI compatibility and bumps the SONAME version[2].
        There are also API changes:

      
        ## Abseil LTS 20250814.0

          
          ### What's New:

          
          - `absl::Mutex` now contains lower-case method names like
        `lock()`
          and `shared_lock()` to align with standard
        C++ mutex methods.
          This allows `absl::Mutex` to be used with
        `std::scoped_lock` and
          friends. The old names are still present
        but may be removed in a
          future release.

          - The RAII Mutex-locker types like `absl::MutexLock`,
          `absl::ReaderMutexLock`, and friends now
        accept references to
          `absl::Mutex`. The pointer-accepting
        constructors are now
          deprecated, and may be removed in a future
        release.

        
          ### Breaking Changes:

          
          - Nullability template types, which were deprecated in the May
        2025
          release, have been removed.

          - `absl::string_view(nullptr)`, which is undefined behavior
          according to the C++ standard, now triggers
        an `assert` failure.
          Note that unless you changed
        `absl/base/options.h`,
          `absl::string_view` is an alias for
        `std::string_view`, so by
          default you will be inheriting the behavior
        of your standard
          library instead of using the Abseil
        implementation.

          - Abseil's hash tables now require a hash function that has a
          return type with `size >=
        sizeof(size_t)`.

      
        Testing in COPR[3] indicates all directly-dependent packages are
        compatible, with a few PR’s mentioned later in this message.
      

        Besides abseil-cpp, I plan to rebuild all dependent packages
        using maintainer/co-maintainer or provenpackager privileges.
        These packages are: 

        
            - bloaty (currently orphaned)

            - buildbox

            - credentials-fetcher

            - CuraEngine_grpc_definitions

            - fastnetmon

            - fcitx5-mozc

            - frr

            - grpc

            - ilbc

            - libarrow

            - libphonenumber

            - mozc

            - onnxruntime

            - opentrep

            - parlaylib 

            - qt6-qtgrpc

            - re2

            - syslog-ng

            - tde2e

            - webrtc-audio-processing

        
        In order to do so, I will need to merge these two PR’s: 

        
            - https://src.fedoraproject.org/rpms/mozc/pull-request/9
        

            - https://src.fedoraproject.org/rpms/onnxruntime/pull-request/12
        

        It looks like webrtc-audio-processing only ends up using
        "header-only" parts of the abseil-cpp API, and doesn’t currently
        link any abseil-cpp shared libraries; still, including it in the
        list above does no harm and might do some good. 

        
        Finally, it looks like marble has a legitimate direct
        BuildRequires on abseil-cpp-devel (in that the build system
        checks for it), but none of the headers are included and none of
        the binary packages ends up linking abseil-cpp libraries, so I
        see no reason to rebuild marble. 

        
        Maintainers of all affected packages should have received this
        email directly (by BCC rather than CC, to keep the message from
        being held for moderation due to a long CC list).

        
        – Ben Beasley (FAS: music) 

        
        [1] https://src.fedoraproject.org/rpms/abseil-cpp/pull-request/31
        

        [2] https://github.com/abseil/abseil-cpp/releases/tag/20250814.0
        

        [3] https://copr.fedorainfracloud.org/coprs/music/abseil-cpp/packages/
        

-- 
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue