<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/apt-pkg/cachefile.cc, branch 2.1.20</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=2.1.20</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=2.1.20'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2021-02-04T10:00:00Z</updated>
<entry>
<title>Use size of the old cache as APT::Cache-Start default</title>
<updated>2021-02-04T10:00:00Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2021-02-03T21:41:56Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=a158e78152316f56b1a324a42a2f00f0a8662ac3'/>
<id>urn:sha1:a158e78152316f56b1a324a42a2f00f0a8662ac3</id>
<content type='text'>
Depending on your configured source 25 MB is hardly enough, so the mmap
housing the cache while it is build has to grow. Repeatedly. We can cut
down on the repeats of this by keeping a record of the size of the old
cache assuming the sizes will remain roughly in the same ballpark.
</content>
</entry>
<entry>
<title>apt(8): Wait for frontend and cache lock</title>
<updated>2020-02-26T19:36:52Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2020-02-26T19:31:03Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=93e1565796b61eb44bec39f50e09a34cbe090178'/>
<id>urn:sha1:93e1565796b61eb44bec39f50e09a34cbe090178</id>
<content type='text'>
This is a rework of !6 with additional stuff for the frontend
lock, so we can lock the frontend lock and then keep looping
over dpkg lock.
</content>
</entry>
<entry>
<title>pkgCacheFile: Only unlock in destructor if locked before</title>
<updated>2018-09-24T10:13:03Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2018-09-24T09:38:55Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=e02297b8e22dae04872fe6fab6dba966de65dbba'/>
<id>urn:sha1:e02297b8e22dae04872fe6fab6dba966de65dbba</id>
<content type='text'>
pkgCacheFile's destructor unlocks the system, which is confusing
if you did not open the cachefile with WithLock set. Create a private
data instance that holds the value of WithLock.

This regression was introduced in commit b2e465d6d32d2dc884f58b94acb7e35f671a87fe:

    Join with aliencode
    Author: jgg
    Date: 2001-02-20 07:03:16 GMT
    Join with aliencode

by replacing a "Lock" member that was only initialized when the lock
was taken by calls to Lock, UnLock; with the latter also taking place
if the former did not occur.

Regression-Of: b2e465d6d32d2dc884f58b94acb7e35f671a87fe
LP: #1794053
</content>
</entry>
<entry>
<title>Remove obsolete RCS keywords</title>
<updated>2018-05-07T11:41:31Z</updated>
<author>
<name>Guillem Jover</name>
<email>guillem@debian.org</email>
</author>
<published>2018-05-06T20:32:41Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=164f1b78d1849a0f33df7352875f86e28f5de06a'/>
<id>urn:sha1:164f1b78d1849a0f33df7352875f86e28f5de06a</id>
<content type='text'>
Prompted-by: Jakub Wilk &lt;jwilk@debian.org&gt;
</content>
</entry>
<entry>
<title>show warnings instead of errors if files are unreadable</title>
<updated>2017-07-26T17:09:04Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2017-07-15T13:08:35Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=51751106976b1c6afa8f7991790db87b239fcc84'/>
<id>urn:sha1:51751106976b1c6afa8f7991790db87b239fcc84</id>
<content type='text'>
We used to fail on unreadable config/preferences/sources files, but at
least for sources we didn't in the past and it seems harsh to refuse to
work because of a single file, especially as the error messages are
inconsistent and end up being silly (like suggesting to run apt update
to fix the problem…).

LP: #1701852
</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>fail instead of segfault on unreadable config files</title>
<updated>2016-05-20T07:37:24Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-05-20T07:37:24Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=fdf9eef4d96a18d0167708499c993e1174251e88'/>
<id>urn:sha1:fdf9eef4d96a18d0167708499c993e1174251e88</id>
<content type='text'>
The report mentions "apt list --upgradable", but there are others which
have inconsistent behavior ranging from segfaulting to doing something
with the partial (and hence incomplete) data. We had a recent report
about sources.list (#818628), this one mentions prefences, the obvious
next step is conf files… so the testcase is adapted to check for all
three in file and directory versions and run a bunch of commands each
time which should all have more or less the same behavior in such a case
(aka error out).

Closes: 824503
</content>
</entry>
<entry>
<title>cachefile: Only set members that were initialized successfully</title>
<updated>2016-03-19T06:19:24Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2016-03-19T00:56:38Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=f40fdaa43271edf98b80c08e20f401b5da591501'/>
<id>urn:sha1:f40fdaa43271edf98b80c08e20f401b5da591501</id>
<content type='text'>
Otherwise, things will just start failing later down the stack,
because (a) the lazy getters do not check if building was successful
and (b) any further getter call would return the invalid object
anyway.

Also initialize VS in pkgCache to nullptr by default.

Closes: #818628
</content>
</entry>
<entry>
<title>get dpkg lock in build-dep if cache was invalid again</title>
<updated>2016-02-10T12:03:00Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-02-10T11:26:49Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=b6f1b480164b454661ddd4fdd3968302c6a3ebf6'/>
<id>urn:sha1:b6f1b480164b454661ddd4fdd3968302c6a3ebf6</id>
<content type='text'>
Regression introduced in a249b3e6fd798935a02b769149c9791a6fa6ef16, which
in the case of an invalid cache would build the first part unlocked and
later pick up the (still unlocked) cache for further processing, so the
system got never locked and apt would end up complaining about being
unable to release the lock at shutdown.

The far more common case of having a valid cache worked as expected and
hence covered up the problem – especially as tests who would have
noticed it are simulations only, which do not lock.

Closes: 814139
Reported-By: Balint Reczey &lt;balint@balintreczey.hu&gt;
Reported-By: Helmut Grohne &lt;helmut@subdivi.de&gt; on IRC
</content>
</entry>
<entry>
<title>deal better with (very) small apt::cache-start values</title>
<updated>2016-01-26T23:15:12Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-01-26T23:15:12Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=a133f79c8766aee5b7d7811285e60b3d311d8473'/>
<id>urn:sha1:a133f79c8766aee5b7d7811285e60b3d311d8473</id>
<content type='text'>
It is a bit academic to support values which aren't big enough to fit even
the hashtables without resizing, but cleaning up ensures that we do the
right thing (aka not segfaulting) even if something goes wrong in these
deep layers. You still can't have very very small values through…

Git-Dch: Ignore
</content>
</entry>
</feed>
