<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/test/libapt/parsedepends_test.cc, branch 2.9.2</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=2.9.2</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=2.9.2'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2024-04-20T12:15:47Z</updated>
<entry>
<title>build: test: Silence warnings in GTest code</title>
<updated>2024-04-20T12:15:47Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2024-04-20T12:09:37Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=4e9a9dbf9bd52d38ab5818f3eb32c8189fd25671'/>
<id>urn:sha1:4e9a9dbf9bd52d38ab5818f3eb32c8189fd25671</id>
<content type='text'>
GTest has a lot of broken things with signed vs unsigned,
and double integer promotions, let's silence them.
</content>
</entry>
<entry>
<title>Allow no spaces for the last dependency in ParseDepends, too</title>
<updated>2024-04-17T09:12:58Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2024-04-17T08:19:40Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=633f6d67a28b375cf1f225f14d3c926e618d46af'/>
<id>urn:sha1:633f6d67a28b375cf1f225f14d3c926e618d46af</id>
<content type='text'>
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
</content>
</entry>
<entry>
<title>Modernize standard library includes</title>
<updated>2024-02-20T12:49:04Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2024-02-20T12:43:08Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=40a75722c43ae24cb9a99d6730a3b25b65819c49'/>
<id>urn:sha1:40a75722c43ae24cb9a99d6730a3b25b65819c49</id>
<content type='text'>
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.
</content>
</entry>
<entry>
<title>Reformat and sort all includes with clang-format</title>
<updated>2017-07-12T11:57:51Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2017-07-12T11:40:41Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=87274d0f22e1dfd99b2e5200e2fe75c1b804eac3'/>
<id>urn:sha1:87274d0f22e1dfd99b2e5200e2fe75c1b804eac3</id>
<content type='text'>
This makes it easier to see which headers includes what.

The changes were done by running

    git grep -l '#\s*include'  \
        | grep -E '.(cc|h)$' \
        | xargs sed -i -E 's/(^\s*)#(\s*)include/\1#\2 include/'

To modify all include lines by adding a space, and then running
./git-clang-format.sh.
</content>
</entry>
<entry>
<title>Run parsedepends_test for two different native archs</title>
<updated>2017-01-02T13:28:05Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2017-01-02T13:25:45Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=ae44d3935267b193e73071f3d110009d492021a6'/>
<id>urn:sha1:ae44d3935267b193e73071f3d110009d492021a6</id>
<content type='text'>
Run the test for kfreebsd-i386 and amd64 and pass "amd64" as
an additional argument to the function. This tests that the
argument is used and thus ParseDepends returns the amd64
results even on a different architecture like i386.
</content>
</entry>
<entry>
<title>support &lt;libc&gt;-&lt;kernel&gt;-&lt;cpu&gt; in architecture specs</title>
<updated>2016-01-31T22:24:59Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-01-31T21:32:45Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=5025879e3fdd705bb0607ff8f51a680749c5972a'/>
<id>urn:sha1:5025879e3fdd705bb0607ff8f51a680749c5972a</id>
<content type='text'>
APT has a different understanding than dpkg (#748936) what matches and
what doesn't match an architecture specification as it isn't converting
back (and forward) to Debian triplets. That has to eventually be solved
some way or the other, but until that happens we change the matching in
apt so that porters can continue their work on non-gnu libc-ports even
if policy doesn't specify that yet (and dpkg just supporting it "by
accident" via triplets).

The initial patch was reformatted, fixed in terms of patterns containing
"any-any", dealing with expanding an arch without libc to gnu while a
pattern expands libc to any, the parsedepends test was fixed (the new
if's were inserted one step too early) and another test just for the
specifications added.

Closes: #812212
Thanks: Bálint Réczey for initial patch
</content>
</entry>
<entry>
<title>implement the updated build profile spec</title>
<updated>2014-10-06T12:43:48Z</updated>
<author>
<name>josch</name>
<email>j.schauer@email.de</email>
</author>
<published>2014-08-19T08:29:29Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=ac81c0f9b79351258d3a29212f7fda312e5afeb5'/>
<id>urn:sha1:ac81c0f9b79351258d3a29212f7fda312e5afeb5</id>
<content type='text'>
</content>
</entry>
<entry>
<title>build: Convert from DebianDoc SGML to DocBook XML</title>
<updated>2014-07-08T11:14:22Z</updated>
<author>
<name>Guillem Jover</name>
<email>guillem@debian.org</email>
</author>
<published>2014-07-02T02:10:37Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=a034d8528bc98e9caf12e024a0d5eeb25f87a500'/>
<id>urn:sha1:a034d8528bc98e9caf12e024a0d5eeb25f87a500</id>
<content type='text'>
</content>
</entry>
<entry>
<title>use Google C++ Testing Framework for libapt tests</title>
<updated>2014-04-16T16:36:14Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2014-04-16T15:09:37Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=f00832cc273e52a47fb88e49849891b771de4e17'/>
<id>urn:sha1:f00832cc273e52a47fb88e49849891b771de4e17</id>
<content type='text'>
My commit 45df0ad2 from 26. Nov 2009 had a little remark:
"The commit also includes a very very simple testapp."
This was never intended to be permanent, but as usually…

The commit adds the needed make magic to compile gtest statically
as it is required and links it against a small runner. All previous
testcase binaries are reimplemented in gtest and combined in this
runner. While most code is a 1:1 translation some had to be rewritten
like compareversion_test.cc, but the coverage remains the same.
</content>
</entry>
<entry>
<title>cleanup headers and especially #includes everywhere</title>
<updated>2014-03-13T12:58:45Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2014-03-05T21:11:25Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=453b82a388013e522b3a1b9fcd6ed0810dab1f4f'/>
<id>urn:sha1:453b82a388013e522b3a1b9fcd6ed0810dab1f4f</id>
<content type='text'>
Beside being a bit cleaner it hopefully also resolves oddball problems
I have with high levels of parallel jobs.

Git-Dch: Ignore
Reported-By: iwyu (include-what-you-use)
</content>
</entry>
</feed>
