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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to