[MIR] abseil

[Didier Roche-Tolomelli]

* Availability

In sync with Debian, built on all architectures
https://launchpad.net/ubuntu/+source/abseil/0~20200923.2-1

(there is a recent update in hirsute proposed failing on some archs)

* Rationale

It's a new Depends from mozc

* Security

No known security issues

https://security-tracker.debian.org/tracker/source-package/abseil
https://people.canonical.com/~ubuntu-security/cve/pkg/abseil.html

* Quality assurance

The desktop is going to subscribe to the package

https://bugs.launchpad.net/ubuntu/+source/abseil
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=abseil

There is a recent build issue but no other report.

The package has upstream tests as part of the build and simple autopkgtests.

* Dependencies

No universe binary dependencies

* Standards compliance

current 4.5 standards-version, debhelper compat 12, dh simple rules

* Maintenance

Upstream is active, the package is maintained in Debian and in sync for Ubuntu

[Didier Roche-Tolomelli (didrocks)]

I have some reservations on the fact that the API and ABI are not stable, and having thus the revision in the soname (actually even, the date!). See more info about symbol tracking in the dedicated section above and why I think this is ok.
Also, there is no official releases but only snapshots.
However, this wouldn’t be the first one in that case being promoted in main and both upstream and debian tracking looks good.

Notes:
Required TODOs:
- version blocked in proposed FTBFS on multiple archs. This needs fixing before final ack.
- as a reminder, once acked, needs a team subscribed before promotion.
Recommended TODOs:
- see the additional notes below (reporting the warning during build for instance)

[Duplication]
There is no other package in main providing the same functionality.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
- no -dev/-debug/-doc packages that need exclusion

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking

[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not parse data formats
- does not open a port
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)

[Common blockers]
OK:
- does have a test suite that runs at build time
- test suite fails will fail the build upon error.
- does have a test suite that runs as autopkgtest
- no translation present, but none needed for this case (user visible)?
- not a python/go package, no extra constraints to consider in that regard

Problems:
- version blocked in proposed FTBFS on multiple archs.
- The package needs a team bug subscriber (agreeing that can be just done just before promoting the package)

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- d/watch is present and looks ok
- Upstream update history is good (no release though, but code maintained)
- Debian/Ubuntu update history is good
- there is no current release, but a recent snapshot is packaged
- promoting this does not seem to cause issues for MOTUs that so far
- no massive Lintian warnings
- d/rules is rather clean
- Does not have Built-Using

Problems:
- No symbols tracking is in place. The package used to have one, but this one was reverted https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966183 due to the fact that there is no stable API or ABI. The package thus force to depend on an exact version and this is a NEW binary package at every new update. This wouldn’t be the first case of this in main (compiz, nux, e-d-s…).
Also, the number of reverse dependencies (outside the current package) is rather small:
$ reverse-depends libabsl20200923
Reverse-Depends
* libabsl-dev
* libgav1-0
* libgav1-bin
* libgrpc++1
* libgrpc10
* python3-grpcio

So, basically 2 sources packages will need a transition (and already needs in universe)
:
- grpc (in sync with Debian)
- libgav1 (in sync with Debian)

As both are in sync with Debian, this doesn’t add more maintainance on us.

[Upstream red flags]
OK:
- no Errors/wa...

[Sebastien Bacher (seb128)]

I've opened a bug in Debian against mozc to discuss dropping the use of that system library, no really so far though, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981269

[Sebastien Bacher (seb128)]

Building mozc without abseil isn't as simple as expected and is an upstream change as well and not only the debian patch.

Updating the MIR status seems that seems the way forward

- Debian is changing the soname with every snapshot, as discussed it's not ideal but it's manageable and ensure there is no incompatible change even if there is no .symbols

- the build issue has been resolved

- the assembler warning is not present when building the current git version, since it's just a gcc warning in the tests could be get the MIR accepted on that basis? we could bisect to find when it got resolved and try to cherrypick a change but if there is no hurry it would probably be best to spend that time on other work instead

Changing back to New and unassigned so it's in the review queue again

[Didier Roche-Tolomelli (didrocks)]

- Ack on soname, as it’s encoded in the binary package name, this is fine by me.
- build issue is indeed solved,
- Ack on the assembler warning not showing up in current upstream git and so, we will naturally get it in ubuntu.

Consequently, ack from the MIR team. Feel free to promote it yourself once you added the team subscriber.

[Sebastien Bacher (seb128)]

Those have been promoted now, abseil libabsl-dev libabsl20200923