offa

@swaragade are you sure? The endpoint is still listed without any deprecation notice: https://developer.atlassian.com/server/bitbucket/how-tos/updating-build-status-for-commits/

The `-v` shorthand is available with [podman 1.6](https://github.com/containers/podman/blob/54dce001cce131bbbdcf16512a4722e080561fc7/RELEASE_NOTES.md#misc-23) (again) . However, as @95jonpet I'd prefer `--version`, especially to avoid confusion with `--volume`'s shorthand.

ping @rsandell

> Well, it's not a real replacement if it still needs the stock Phone app. And I'd say it's rather messy and RAM-unfriendly to have two apps handle your calls...

Does this appear when this library is used in client code or even when compiling the test?

Try with an ed25519 key if you are using a RSA. Many distributions have dropped RSA support already.

@oleg-nenashev I've created a PR for your branch which fixes the conflicts.

`addField()` doesn't support unsigned types yet. If your values fit into a `int64_t` you can cast them. Support for unsigned types is possible to implement though.

Thanks for the ping, I'm quite behind my todos. According to [docs](https://docs.influxdata.com/influxdb/v1.8/write_protocols/line_protocol_reference/#data-types), the only integer type is *signed* 64-bit. ~~So deprecating the current `addField()` and adding one with `uint64` instead...

Thinking further, I'm not sure whether `uint64` is a good idea, given `uint64` can hold a larger value than the specified `int64`. Update: Influxdb 2.x supports uint64: https://docs.influxdata.com/influxdb/cloud/reference/syntax/line-protocol/#uinteger