| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
| |
Work is under way in Debian to remove tzdata from the buildd chroots,
but Abseil needs a system tzdata to use while running tests. Add
`Build-Depends: tzdata` to ensure that tests always have a tzdata
available.
Thanks to Sebastian Ramacher <sramacher@debian.org> for help identifying
this issue.
|
| |
|
|
|
|
| |
Add a Build-Depends on dpkg-dev (>= 1.22.5) to ensure this package
doesn’t migrate from unstable to testing until the ongoing time_t
transition is ready for it (https://bugs.debian.org/1059535#39).
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Abseil 20230125.3 exposes libraries that were formerly internal
(“test-only”) so that other packages’ unit tests can refer to them [1].
Some of the new libraries depend on Google Mock, which Debian only ships
as a static library; as a result, the new libraries can only be shipped
statically as well. Historically, however, Abseil’s Debian packaging has
linked Abseil’s unit tests dynamically to improve build speed. (Google
Mock was built as a one-off shared library during this process, but it
was only ever used in unit tests and was never shipped to users.) Static
Abseil builds were unaware that Google Mock existed, which prevented
sbuild from building the new libraries [2].
To rectify the situation, change Abseil’s Debian packaging to link
Abseil unit tests statically and to ship the new libraries as static
archives. Also make libabsl-dev recommend libgmock-dev, since the new
libraries are useless without a corresponding Google Mock build.
[1] https://github.com/abseil/abseil-cpp/pull/1442
[2] https://bugs.debian.org/1034908
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Per release-team’s recent request that maintainers support the nocheck
profile <E1oit90-0073rh-LX@respighi.debian.org>, annotate googletest
with <!nocheck> and disable tests in debian/rules if that profile is
set.
|
| | |
|
| |
|
|
|
| |
Abseil 20220623 requires a fairly new googletest for tests to compile
correctly. Record that dependency in debian/control.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Abseil 20210324.1 respects multiarch when installing pkg-config files
now, so we don’t need to install them from usr/lib/pkgconfig. This
means we don’t need debhelper 13 (see
9c4d4dbaa118a180f6d0e681dfe89efd22ae1cf4), so go back to
debhelper-compat 12.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Abseil now ships pkg-config files. Install them with libabsl-dev, using
debhelper 13’s variable substitution support to handle multiarch.
Expand libabsl-dev’ Recommends: cmake to
Recommends: cmake | pkg-config to reflect the fact that it’s now
reasonable to use Abseil without CMake.
|
| |
|
|
|
| |
Abseil now supports only GCC >=5.1. Update debian/control to recommend
that with libabsl-dev.
|
| |
|
|
|
|
| |
Bump package versions and names to reflect the new Abseil LTS. Remove
patches that have been incorporated upstream, and refresh other
patches.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
I’m still working to fix unit tests on non-amd64 platforms, but this
package needs to migrate. Disable unit tests everywhere they don’t
work.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Now that https://bugs.debian.org/970943 has been resolved and a new Git
snapshot of googletest has made it to testing, reenable Abseil unit
tests and run them as part of the build process. This does not change
the package as viewed by dependents; it only provides greater assurance
of correctness when an upload occurs. (It probably would have caught
http://bugs.debian.org/973492, for instance.)
Run the tests against the shared libraries, not the static ones, to
more accurately simulate the conditions under which dependents are
likely to use Abseil.
|
| |
|
|
|
|
| |
Bump package versions and names to reflect the new Abseil LTS. Remove
patches that have been incorporated upstream, and refresh the
configuration patch.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Remove the symbols file and replace it with an shlibs file. Since Abseil
is almost certain to break ABI with every release, maintaining
fine-grained symbol histories is not terribly useful anyway;
furthermore, since Abseil is a C++ library, maintaining a symbols file
is a lot of work.
Bug: https://bugs.debian.org/966183
|
| |
|
|
|
|
|
|
| |
Rebuild abseil against GCC 9, the version currently in unstable, and
update the symbols file. Additionally, rework the symbols file using
pkg-kde-tools, which offers some automation for building large symbols
files. This does mean that the symbols file now contains mangled names,
but it’s still easily inspected through c++filt.
|
| |
|
|
|
|
|
|
| |
ftpmaster has voiced concern about having dozens of tiny packages with
ABI identifiers in their names, so combine all of them into a single
binary package. Abseil now builds only two packages--libabsl20200225,
which contains shared libraries, and libabsl-dev, which contains
headers and archives.
|
| | |
|
| |
|
|
|
|
|
| |
Install Abseil’s CMake support files. Some of these files are
autogenerated, and the generator produces files with a googletest
dependency if Abseil is built with unit tests enabled; to prevent this,
turn off unit tests.
|
|
|
Create basic packaging for Abseil. There’s still work to be done –
there are no autopkgtests, and this package doesn’t install Abseil’s
CMake integration. However, you can install the binary packages and
build programs that link the libraries.
|
Benjamin Barenblat