| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
The old way of handling this was that pkgAcqMetaIndex was responsible
to check/move both Release and Release.gpg in place. This breaks
the assumption of the transaction that each pkgAcquire::Item has
a single File that its responsible for.
|
|
|
|
Thanks to Jakub Wilk for the bugreport.
Closes: #754904
|
|
This avoid the subtle problem that someone might have a directory
with the same package name as the build-depends he/she is trying
to fetch. Also print a note that the specific file/dir is used.
|
|
Conflicts:
apt-pkg/deb/deblistparser.cc
doc/po/apt-doc.pot
doc/po/de.po
doc/po/es.po
doc/po/fr.po
doc/po/it.po
doc/po/ja.po
doc/po/pl.po
doc/po/pt.po
doc/po/pt_BR.po
po/da.po
po/mr.po
po/vi.po
|
|
The behaviour of echo "\tA\t" differs between dash/zsh which interprets
the \t as tab and bash which prints it literally. Similar things happen
for other escape sequences – without the -e flag.
Switching to printf makes this more painless^Wportable, so that the
tests are also working correctly with bash as sh.
(commit message by committer, patch otherwise unmodified)
|
|
Git-Dch: ignore
|
|
bash as sh doesn't like it, too.
Git-Dch: Ignore
|
|
Conflicts:
apt-private/private-install.cc
|
|
|
|
debian/experimental
|
|
Conflicts:
debian/changelog
|
|
|
|
|
|
|
|
|
|
|
|
|
|
'mvo/bugfix/apt-get-source-unauthenticated-warning' into debian/sid
|
|
|
|
Closes: 742835
|
|
In commit 21b3eac8 I promoted the check for installable dependencies to
a pre-install check, which also reverts to a known good candidate (the
installed version) if it fails. This revert was done even for user
requested candidate switches which disabled our Broken detection so that
install requests which are impossible to satisfy do not fail anymore,
but print an (incomplete) solution proposal and then exit successfully.
Closes: 745046
|
|
|
|
This will show the same unauthenticated warning for source packages
as for binary packages and will not download a source package if
it is unauthenticated. This can be overridden with
--allow-unauthenticated
Closes: #749795
|
|
Git-Dch: Ignore
|
|
Git-Dch: Ignore
|
|
Adds also a small testcase for EDSP
Git-Dch: Ignore
|
|
Conflicts:
test/integration/test-bug-747261-arch-specific-conflicts
|
|
dpkg on Ubuntu 12.04 does not seem to support parsing arch-specific
dependencies, so we try to detect if we face such a dpkg in the test.
In the other test the order depends on libdb, which changes per arch, so
we just run it through our sorting binary and be happy (hopefully).
Git-Dch: Ignore
|
|
As outlined in #748355 apt segfaulted if it encountered a loop between a
package pre-depending on a package conflicting with the previous as it
ended up in an endless loop trying to unpack 'the other package'.
In this specific case as an essential package is involved a lot of force
needs to be applied, but can also be caused by 'normal' tight loops and
highlights a problem in how we handle breaks which we want to avoid.
The fix comes in multiple entangled changes:
1. All Smart* calls are guarded with loop detection. Some already had it,
some had parts of it, some did it incorrect, and some didn't even try.
2. temporary removes to avoid a loop (which is done if a loop is
detected) prevent the unpack of this looping package (we tried to unpack
it to avoid the conflict/breaks, but due to a loop we couldn't, so we
remove/deconfigure it instead which means we can't unpack it now)
3. handle conflicts and breaks very similar instead of duplicating most
of the code. The only remaining difference is, as it should:
deconfigure is enough for breaks, for conflicts we need the big hammer
|
|
Git-Dch: Ignore
|
|
The by-hash can be configured on a per-hostname basis and a Release
file can indicate that it has by-hash support via a new flag.
The location of the hash now matches the AptByHash spec
|
|
This implements a apt update schema that get the indexfiles by the
hash instead of the name. The rational is that updates to the archive
servers/mirrors are not atomic so the client may have the previous
version of the Release file when the server updates to a new
Release file and new Packages/Sources/Translations indexes. By
keeping the files around by their hash we can still get the previous
indexfile without a hashsum mismatch.
Enable with APT::Acquire::By-Hash=1
|
|
Closes: 748389
|
|
In bugreport #747261 I confirmed with this testcase that apt actually
supports the requested architecture-specific conflicts already since
2012 with commit cef094c2ec8214b2783a2ac3aa70cf835381eae1.
The old test only does simulations which are handy to check apt,
this one builds 'real' packages to see if dpkg agrees with us.
Git-Dch: Ignore
|
|
Version/Architecture information in a Translation-$lang file is
not allowed, so don't try to parse it. This is a fix for a bugreport
where a Translation-en file contained the content of the regular
Packages file (probably due to local FS corruption). This lead to
strange error messages on file download.
Thanks to Thomas Reusch for the report.
|
|
dpkg on Ubuntu 12.04 does not seem to support parsing arch-specific
dependencies, so we try to detect if we face such a dpkg in the test.
In the other test the order depends on libdb, which changes per arch, so
we just run it through our sorting binary and be happy (hopefully).
Git-Dch: Ignore
|
|
In bugreport #747261 I confirmed with this testcase that apt actually
supports the requested architecture-specific conflicts already since
2012 with commit cef094c2ec8214b2783a2ac3aa70cf835381eae1.
The old test only does simulations which are handy to check apt,
this one builds 'real' packages to see if dpkg agrees with us.
Git-Dch: Ignore
|
|
The cache heavily depends on the architecture(s) it is build for,
especially if you move from single- to multiarch. Adding a new
architecture to dpkg therefore has to be detected and must invalidate
the cache so that we don't operate on incorrect data.
The incorrect data will prevent us from doing otherwise sensible
actions (it doesn't allow bad things to happen) and the recovery is
simple and automatic in most cases, so this hides pretty well and is
also not as serious as it might sound at first.
Closes: 745036
|
|
Removes the 256 fields limit, deals consistently with spaces littered
all over the place and is even a tiny bit faster than before.
Even comes with a bunch of new tests to validate these claims.
|
|
It seems unlikely for now that proper archives will carry multiple
Description-* stanzas in the Packages (or Translation-*) file, but
sometimes apt eats its own output as shown by the usage of the CD team
and it would be interesting to let apt output multiple translations
e.g. in 'apt-cache show'.
|
|
Now that methods have the expected hashes available they can check if
the response from the server is what they expected. Pipelining is one of
those areas in which servers can mess up by not supporting it properly,
which forced us to disable it for the time being. Now, we check if
we got a response out of order, which we can not only use to disable
pipelining automatically for the next requests, but we can fix it up
just like the server responded in proper order for the current requests.
To ensure that this little trick works pipelining is only attempt if we
have hashsums for all the files in the chain which in theory reduces the
use of pipelining usage even on the many servers which work properly,
but in practice only the InRelease file (or similar such) will be
requested without a hashsum – and as it is the only file requested in
that stage it can't be pipelined even if we wanted to.
Some minor annoyances remain: The display of the progress we have
doesn't reflect this change, so it looks like the same package gets
downloaded multiple times while others aren't at all. Further more,
partial files are not supported in this recovery as the received data
was appended to the wrong file, so the hashsum doesn't match.
Both seem to be minor enough to reenable pipelining by default until
further notice through to test if it really solves the problem.
This therefore reverts commit 8221431757c775ee875a061b184b5f6f2330f928.
|
|
Now that libapts acquire system happily passes around hashes and can be
made to support new ones without an ABI break in the future, we can
free ftparchive from all the deprecation warnings the last commit
introduced for it.
The goal here isn't to preserve ABI as we have none to keep here, but to
help avoiding introduction problems of 'new' hashes later as bugs creep
into the copy&paste parts, so short/less of them is good.
|
|
It is not very extensible to have the supported Hashes hardcoded
everywhere and especially if it is part of virtual method names.
It is also possible that a method does not support the 'best' hash
(yet), so we might end up not being able to verify a file even though we
have a common subset of supported hashes. And those are just two of the
cases in which it is handy to have a more dynamic selection.
The downside is that this is a MAJOR API break, but the HashStringList
has a string constructor for compatibility, so with a bit of luck the
few frontends playing with the acquire system directly are okay.
|
