dist-upgrade is supposed to be an alias for full-upgrade in apt, but
dist-upgrade was the only command recognized of the two in the option
and flags recognition code.
extract travis installs from build-depends automatically
I forgot to add libgtest-dev to the list of packages to install on
travis, so this slightly hacky oneliner might prevent us from having
the same problem again if we happen to change dependencies again.
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.
fseek and co do this to their eof-flags and it is more logic this way as
we will usually seek away from the end (e.g. to re-read the file).
The commit also improves the testcase further and adds a test for the
binary compressor codepath (as gz, bzip2 and xz are handled by
libraries) via the use of 'rev' as a 'compressor'.
force fancy progressbar redraw on window size change
We always reacted on the size change, but the bar is only redraw if the
precentage changes, which can take quiet a while in big upgrades, so
with a bit of refactoring we can now call for a redraw immediate to fix
this.
This refactor also helps in avoiding obscure pitfalls clangs static
analyser was complaining about (namely failure of ioctl resulting in
garbage values in the struct).
Instructing gcc (or clang) to prepare for capturing coverage data is
easy: Just build with: CXXFLAGS=--coverage
The hard part is that our buildsystem uses relative paths and so
confuses the hell out of lcov as it assumes this way that all our *.cc
files are in the same directory… by changing to absolute paths in the
compile rules we solve this problem.
Still not perfect as it refers to build/include files for most headers
and our forking/threading code isn't properly captured, but good enough
to see red reports for now:
CXXFLAGS=--coverage make
make test
./test/integration/run-tests -q
lcov --no-external --directory . --capture --output-file apt.info
genhtml --output-directory ./coverage/ apt.info
consider priorities only for downloadable pkgs in resolver
A package which can't be downloaded anymore is very likely dropped from
a release and can therefore no longer be 'standard' (or similar). We
therefore do not grant points for them anymore and demote them to
prio:extra instead which helps other packages breaking them away even if
they have a lower priority.
The testcase was initially created by Michael Vogt and just amended.
We now do Open, Write and Read (the later multiple ways) for each
permission and each compressor we have configured to cover more cases
and especially ensure that compressors do not change our premissions.
This test is also to be credited for discovering the skippos-fix.
deal with umask only if we really need to for mkstemp
As the comment actually says: open() does the umask dance by itself, so
we don't need to do it for it. We have to do it after mkstemp in Atomic
though, so move it into the if.
Also removes the "micro-optimisation" "FilePermissions == 600" as it
doesn't trigger at the moment anyway as 600 != 0600.
FileFd code knows how to deal with such a compressor, so it isn't a
problem, but it is absolutely not needed as we already have an
(matching) identity compressor with '.' earlier in the list.
use wildcard to get files in our library makefiles
The explicit listing is a pain every time you want to add a file to the
list and serves no propose as we list all files there anyway, so this is
not only easier but also documents this fact.
Michael Vogt [Wed, 9 Apr 2014 08:24:47 +0000 (10:24 +0200)]
Rename FileFd::Open() Perms to AccessMode
Bug lp:#1304657 was caused by confusion around the name Perms.
The new name AccessMode should make it clear that its not the
literal file permissions but instead the AccessMode passed to
open() (i.e. the umask needs to be applied)
Michael Vogt [Wed, 9 Apr 2014 08:12:10 +0000 (10:12 +0200)]
Fix insecure file permissions when using FileFd with OpenMode::Atomic
Commit 7335eebea6dd43581d4650a8818b06383ab89901 introduced a bug
that caused FileFd to create insecure permissions when FileFd::Atomic
is used. This commit fixes the permissions and adds a test.
The bug is most likely caused by the confusing "Perm" parameter
that is passed to Open() - its not the file permissions but intead
the "mode" part of open/creat.
discard candidates via IsInstallOk to allow override
In commit 446551c8 I changed MarkInstall to discard the candidate if the
candidate can't satisfy the dependency. This breaks interactive solvers
like aptitude which can change the candidate on-the-fly later.
In commit df77d8a5 I introduced this 'early' loop-breaking to begin with
which can't be that helpful for interactive solvers as well, but makes
perfect sense for non-interactives to stop them from exploring trees
which can't be satisfied, but it isn't perfect as ideally we would check
this before auto-installing the first dependency.
This commit therefore moves the loop into its own IsInstallOk hook so
that frontends can override this check if they want to and in exchange
removes the loop-breaking from MarkInstall itself and does it before any
dependency is installed.
do IsInstallOk call in MarkInstall unconditionally
Hooked checks could be influenced by AutoInst as a lot can happen
between a call without and one with this bit set. The real cache-hit
check is above this call already. Individual hooked checks can then
inspect the state if they want to cache. Calling them multiple times
shouldn't be a problem either way.
We have to properly close our pseudo terminals even in error cases
before we call post-invoke scripts. This is done now by breaking from
the dpkg calling loop instead of copying the handling, which did it in
the wrong order before.
This also ensures that our state file is written in error cases to
record autobit and co as this was forgotten before.
This methods should not be used by anyone expect the library itself as
they are helpers for the specific class and therefore perfect candidates
for hidding.
While it is a huge undertaking to enable it for our public libraries as
basically everything we exported so far could be seen as public
interface our private library is new and under our full control, so we
can do whatever we like with it. The benefits are not that big in return
of course, but it reduces the size a bit, so thats great nontheless.
only consider versioned kernel packages in autoremove
Metapackages like "linux-image-amd64" are otherwise matched by our
extraction as well, which later on can't be successfully compared via
dpkg --compare-versions as the 'amd64' bit isn't a version number.
(Luckily none of our architectures starts with a digit.)
This was broken by me in 0.9.16 as I moved a shell-glob matcher to a
regex-based one which has slightly different semantics regarding '*'.
It can happen that content in our buffer is not enough to produce a
meaningful output in which case no output is created by liblzma, but
still reports that everything is okay and we should go on.
The code assumes it has reached the end through if it encounters a null
read, so this commit makes it so that it looks like this read was
interrupted just like the lowlevel read() on uncompressed files could.
It subsequently fixes the issue with that as well as until now our loop
would still break even if we wanted it to continue on.
(This bug triggers our usual "Hash sum mismatch" error)
Reported-By: Stefan Lippers-Hollmann <s.L-H@gmx.de>
Fix handling of autoclosing for compressed files (Closes: #741685)
AutoClose is both an argument in OpenDescriptor() and an enum. In
commit 84baaae93badc2da7c1f4f356456762895cef278 code using the AutoClose
parameter was moved to OpenDescriptorInternal(). In that function,
AutoClose meant the enum value, so the check was always false.
use the pretty fullname of a pkg as download desciption
Otherwise the "WARNING: The following packages cannot be authenticated!"
messages does not include the architecture of the package, so it would
be slightly misinformative.
We have xz/lzma support for a while, but only via an external binary
provided by xz-utils. Now that the Debian archive provides xz by default
and dpkg pre-depends on the library provided by liblzma-dev we can switch
now to use this library as well to avoid requiring an external binary.
For now the binary is in a prio:required package, but this might change
in the future.
API wise it is quiet similar to bz2 code expect that it doesn't provide
file I/O methods, so we piece this together on our own.
The framework can be configured to use different compression algorithms
to test different ones, but a testcase testing for gz support should
always be run with gz, regardless of what compressions are configured
otherwise.
In #737085 we see that apt can be confused if informations about
versions only differ slightly. This commit adds a way of at least adding
a few more data points with the next abi break to help a bit with it.
As we deal with regex matchers here the dots are treated as wildcards if
we don't take care of escaping them. Not very likely that this could be
a real-world problem, but just to be sure.
add ".*-{kernel,modules}-$KERVER" matcher for hook
Pre-build kernel modules (like those build with module-assistent) are
commonly named in this way and it should be ungeneric enough to be added
by default for everyone.
kfreebsd as well as hurd kernel packages call the postinst script as
well so we just need to enable the correct parsing for installed
packages and disable the "protect every version" hammer for them.
use a configurable list of versioned kernel packages
With APT::VersionedKernelPackages users have the option of adding
packages like pre-build out-of-tree modules to the list of automatically
protected from being autoremoved.
Wojciech Górski [Mon, 10 Mar 2014 01:07:05 +0000 (02:07 +0100)]
fix polish --install-suggests text in apt-get manpage
Description of the --install-suggests option is wrong in the polish
apt-get man page. The actual meaning of this option is the opposite
to what is written in the manual.
support very long mtab entries in mountpoint discovery
Old code limited lines to 250 characters which is probably enough for
everybody, but who knows… It also takes care of device nodes which start
with the same prefix.
projects / apt.git / log
