<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/test/interactive-helper, branch 2.9.1</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=2.9.1</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=2.9.1'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2024-02-20T12:49:04Z</updated>
<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>interactive-helper: Undefine _FORTIFY_SOURCE</title>
<updated>2022-09-17T03:07:40Z</updated>
<author>
<name>Khem Raj</name>
<email>raj.khem@gmail.com</email>
</author>
<published>2022-09-17T03:04:43Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=81a5256298f1e4403591bdaf95957e832da75d31'/>
<id>urn:sha1:81a5256298f1e4403591bdaf95957e832da75d31</id>
<content type='text'>
This ensures that it compiles when clang compiler is passing
-DFORTIFY_SOURCES=2

Signed-off-by: Khem Raj &lt;raj.khem@gmail.com&gt;
</content>
</entry>
<entry>
<title>Include our config.h in all C++ files to avoid ODR violations</title>
<updated>2022-05-07T08:45:44Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2022-04-22T15:05:36Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=320245536a7ad21606286d9dcf54acf3bdf096c6'/>
<id>urn:sha1:320245536a7ad21606286d9dcf54acf3bdf096c6</id>
<content type='text'>
Some of our headers use APT_COMPILING_APT trickery to avoid exposing too
broadly details we don't want external clients to know and make use of.
The flip-side is that this can lead to different compilation units
seeing different definitions if they aren't all using the same config.
</content>
</entry>
<entry>
<title>Link interactive helpers against system libapt for autopkgtest</title>
<updated>2022-05-07T08:45:44Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2022-04-20T23:45:45Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=8d8b45a96ceceb015f7836cf25b99279c2f377b9'/>
<id>urn:sha1:8d8b45a96ceceb015f7836cf25b99279c2f377b9</id>
<content type='text'>
Building the library just so we can build the helpers against it is not
only wasteful but as we are supposed to test the system we can use that
as an additional simple smoke test before the real testing starts.
</content>
</entry>
<entry>
<title>Fix build failure with gcc-12 due to missing include</title>
<updated>2022-03-21T01:57:24Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2022-03-20T13:24:28Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=4dd5e241af25eeac5d1b6b61b73aa73614130d7c'/>
<id>urn:sha1:4dd5e241af25eeac5d1b6b61b73aa73614130d7c</id>
<content type='text'>
apt/test/interactive-helper/aptwebserver.cc: In function ‘std::string HTMLEncode(std::string)’:
error: variable ‘constexpr const std::array&lt;std::array&lt;const char*, 2&gt;, 6&gt; htmlencode’ has initializer but incomplete type

Reported-By: Helmut Grohne on IRC
</content>
</entry>
<entry>
<title>Use exact If-Range match in our test webserver</title>
<updated>2021-09-16T20:40:05Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2021-09-16T20:02:26Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=1edf8551cef0a7db7fdcdd5d6b06aec2ea7bb70d'/>
<id>urn:sha1:1edf8551cef0a7db7fdcdd5d6b06aec2ea7bb70d</id>
<content type='text'>
RFC7233 3.2 If-Range specifies the comparison to be an exact match,
not a less or equal, which makes no sense in this context anyhow.
Our server exists only to write our tests against it so this isn't much
of a practical issue. I did confirm with a crashing server that no test
(silently) depends on this or exhibits a different behaviour not
explicitly checked for.
</content>
</entry>
<entry>
<title>Increase recursion limits from 100 to 3000</title>
<updated>2021-08-29T12:23:26Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2021-08-29T11:50:31Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=5f6bbfa53c32ec30aff6a2bc8c412616049eab18'/>
<id>urn:sha1:5f6bbfa53c32ec30aff6a2bc8c412616049eab18</id>
<content type='text'>
If you install dpkg on an empty status file with all recommends and
suggests apt wants to install 4000+ packages. The deepest chain
seemingly being 236 steps long. And dpkg isn't even the worst (~259).

That is a problem as libapt has a hardcoded recursion limit for
MarkInstall and friends … set to 100. We are saved by the fact that
chains without suggests are much shorter (dpkg has 5, max seems ~43),
but I ignored Conflicts in these chains, which typically trigger
upgrades, so if two of the worst are chained together we suddenly get
dangerously close to the limit still.

So, lets just increase the limit into oblivion as it is really just a
safety measure we should not be running into to begin with. MarkPackage
was running years without it after all. 3000 is picked as a nice number
as any other and because it is roughly the half of the stack crashs I
saw previously in this branch.
</content>
</entry>
<entry>
<title>Adjust loops to use size_t instead of int</title>
<updated>2021-02-09T22:49:31Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2021-02-09T22:49:31Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=ea114447ee44908c75f4ddc19a0521260832668d'/>
<id>urn:sha1:ea114447ee44908c75f4ddc19a0521260832668d</id>
<content type='text'>
Gbp-Dch: ignore
</content>
</entry>
<entry>
<title>Fix test suite regression from StrToNum fixes</title>
<updated>2021-02-09T22:33:47Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2021-02-09T22:29:05Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=6284c8221da94ab6b4262795e6a7990fc3655848'/>
<id>urn:sha1:6284c8221da94ab6b4262795e6a7990fc3655848</id>
<content type='text'>
We ignored the failure from strtoul() that those test cases had values
out of range, hence they passed before, but now failed on 32-bit
platforms because we use strtoull() and do the limit check ourselves.

Move the tarball generator for test-github-111-invalid-armember to the
createdeb helper, and fix the helper to set all the numbers for like uid
and stuff to 0 instead of the maximum value the fields support (all 7s).

Regression-Of: e0743a85c5f5f2f83d91c305450e8ba192194cd8
</content>
</entry>
<entry>
<title>Don't re-encode encoded URIs in pkgAcqFile</title>
<updated>2020-12-18T19:45:35Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2020-07-10T18:19:31Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=a5859bafdaa6bcf12934d0fb1715a5940965e13a'/>
<id>urn:sha1:a5859bafdaa6bcf12934d0fb1715a5940965e13a</id>
<content type='text'>
This commit potentially breaks code feeding apt an encoded URI using a
method which does not get URIs send encoded. The webserverconfig
requests in our tests are an example for this – but they only worked
before if the server was expecting a double encoding as that was what
was happening to an encoded URI: so unlikely to work as expected in
practice.

Now with the new methods we can drop this double encoding and rely on
the URI being passed properly (and without modification) between the
layers so that passing in encoded URIs should now work correctly.
</content>
</entry>
</feed>
