apt/test/libapt, branch 2.9.14

Fix expired std::string usage in APT::StringView testcase

2024-11-22T12:11:13Z

The anonymous std::string we were using here to create the view expires after the construction of the view and so the gcc warning | warning: ‘’ may be used uninitialized [-Wmaybe-uninitialized] is correct in that the memory we are pointing to is potentially overridden/reused already, if a bit roundabout in saying so.

test/libapt/strutil_test.cc: APT::StringView -> std::string_view

2024-11-12T17:18:27Z

gpgv: Add IsAssertedPubKeyAlgo() function

2024-07-15T17:17:20Z

This checks whether a public key algorithm is asserted.

Deal better with spurious spaces in arch restrictions

2024-05-16T22:15:26Z

Another instance of our parser written for sane clean input, but nowadays used also for user-provided input which can contain very many strange formatting and especially white spaces all over the place. Closes: #1071219

build: test: Silence warnings in GTest code

2024-04-20T12:15:47Z

GTest has a lot of broken things with signed vs unsigned, and double integer promotions, let's silence them.

test: configuration: color: reset _config after tests

2024-04-20T12:15:47Z

This avoids us polluting the configuration for later tests, since the test order apparently is not deterministic. We probably should fix some common test case thingy instead.

Add APT::Configuration::color helper to colorize things

2024-04-19T14:58:24Z

Allow no spaces for the last dependency in ParseDepends, too

2024-04-17T09:12:58Z

All other entries in a dependency line get substantial leeway about the amount of spaces surrounding the entry itself and its individual parts, but the very last entry was required to have a version constraint be at least 4 chars long (excluding opening bracket and spaces following it), so if the version is short and a single-char relation used a space had to make up for it. This is a bit unfair in comparison to the other entries who do not have such unreasonable demands, so we reduce our demand to 3 chars or longer, which is satisfied by "=1)". If it is a good idea to hate spaces that much remains unanswered by this commit, but in practice most tools (re)writing the files we parse will include spaces, so its only in files (or on the satisfy command line) directly edited by users that we can encounter such a situation, which is a relatively new development given this line came unchanged from the introduction of this method in 1998. LP: #2061834

apt: Use unicode install progress bar on UTF-8 locales

2024-04-13T21:59:41Z

This produces a much more appealing progress bar and it can even show parts of the progress being done.

Modernize standard library includes

2024-02-20T12:49:04Z

This was automated with sed and git-clang-format, and then I had to fix up the top of policy.cc by hand as git-clang-format accidentally indented it by two spaces.