| 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.
|
|
|
|
|
|
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
|
|
|
|
debian/experimental
|
|
Reported-By: clang++ -Werror
Conflicts:
apt-pkg/acquire-item.cc
apt-pkg/acquire-item.h
apt-pkg/deb/debmetaindex.h
|
|
|
|
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
|
|
debian/experimental
Conflicts:
apt-pkg/acquire-item.cc
apt-pkg/acquire-item.h
|
|
pkgAcq{DiffIndex,IndexMerge,pkgAcqBaseIndex, pkgAcqIndex}
|
|
If one of the pkgAcqIndex{,Merge}Diffs fails, they will run
pkgAcqIndex() which needs the IndexTarget/indexRecords data.
So we pass it along.
|
|
Beside being another big API break with hopefully zero fallout in
reality it avoids having the same member and helper code in each and
every subclass.
|
|
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.
|
|
debian/experimental
|
|
bugfix/update-progress-reporting
|
|
debian/experimental
|
|
debian/experimental
|
|
Conflicts:
apt-pkg/cachefilter.h
apt-pkg/contrib/fileutl.cc
apt-pkg/contrib/netrc.h
apt-pkg/deb/debsrcrecords.cc
apt-pkg/init.h
apt-pkg/pkgcache.cc
debian/apt.install.in
debian/changelog
|
|
gcc reports in testcase ./test-bug-596498-trusted-unsigned-repo:
apt-pkg/acquire-item.cc:1059:7: runtime error: load of value 234, which
is not a valid value for type 'bool'
This happens as the bool Verify is initialized only in one of the two
constructors of the pkgAcqIndex class. It isn't a problem through as the
verification controlled by this flag is optional and used to fail early
on garbage files (like network portal pages) instead of later on in the
hashsum verification or while parsing (the then untrusted) file.
Reported-By: gcc-4.9 -fsanitize=undefined
|
|
|
|
used to create a proper pkgAcqIndex() with size information
|
|
fetcher
|
|
with the correct extension
|
|
progress information
|
|
|
|
Otherwise the "WARNING: The following packages cannot be authenticated!"
messages does not include the architecture of the package, so it would
be slightly misinformative.
|
|
Git-Dch: Ignore
Reported-By: gcc -Wsuggest-attribute={pure,const,noreturn}
|
|
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)
|
|
Reported-By: gcc -Wunused-parameter
Git-Dch: Ignore
|
|
Git-Dch: Ignore
Reported-By: gcc -Wuseless-cast
|
|
Conflicts:
apt-private/private-list.cc
configure.ac
debian/apt.install.in
debian/changelog
|
|
|
|
|
