| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
The helper expects to be told if it should generate messages, not where
these messages should be printed – as it isn't printing such messages,
but puts them in _error. apt-get uses in other methods a helper
specialisation which does also print stuff to a stream through, so this
is likely a copy&paste error.
Git-Dch: Ignore
|
|
auto-removal fix, with inspiration drawn from the patches and conversation from http://bugs.debian.org/793360 (LP: #1479207)
|
|
|
|
This could allow an attacker to mark a package as installed in a
remote package index, as long as the package was not listed in
the dpkg status file.
This way, an attacker could force the installation of a package
during a dist-upgrade, by providing two packages in an index,
an older marked as installed, and a newer - apt would "upgrade"
to the newer version.
|
|
|
|
|
|
In 50ef3344c3afaaf9943142906b2f976a0337d264 (and similar for other
branches), while 'fixing' the edgecase of a package being in multiple
sections (e.g. moved from libs to oldlibs in newer releases) I
accidently broke the feature itself completely by operating on the
package itself and no longer on its dependencies…
The behaviour isn't ideal in multiple ways, which we are hopefully able
to fix with new ideas as mentioned in the buglog, but until then the
functionality of this "hack" should be restored.
Reported-By: Raphaël Hertzog <hertzog@debian.org>
Tested-By: Adam Conrad <adconrad@ubuntu.com>
Closes: 793360
LP: 1479207
Thanks: Raphaël Hertzog and Adam Conrad for detailed reports and initial patches
|
|
The siblings of this message are all guarded as debug messages, just this
one had it missing and subsequently causes display issues if triggered,
which, given that clog is an alias for cerr, end up on stderr and
therefore are reported as problems by tools only showing the stderr
like our own cron script.
[Backport of f4c7a238f4c29ac9b1e1172f103ab7dec5c5807d]
Closes: 793444
|
|
|
|
Of course, the versions noted for the symbol are incorrect in sofar as
there is no std::__cxx11::basic_string symbol in apt 0.8.0 – but there
is also no libapt-pkg4.16 in that version. The version hence denotes the
appearance of the function in the library, not of the mangled symbol so
you can jugde by looking at the version if a backport would work out…
|
|
Some of the 'simpler' abi changes are included in /sid already guarded
behind #if's and now that we dumped the ABI fpr gcc5 they trigger.
It would probably not hurt to have them trigger and it is an abi break
anyway, but there isn't much point to it and it would be really annoying
if one of them turns out to be a problem as these changes aren't as well
tested as the 'old' abi.
It is slightly incorrect to check for abi >= 17 as /experimental with
this (and other changes) is abi = 15 currently, but writing the correct
check would be just too insane for this dead ends branch. Final
/experimental is probably better of increasing APT_PKG_MAJOR anyhow.
|
|
[ Commited in debian/experimental as
40bd06bdb5e6b90aa24762300567d0650dbda751 ]
Closes: 776702
|
|
[ Commited in debian/experimental as
b55ec4203f7a99d380903911f8839aba2a65e27e ]
Closes: 782122
|
|
[ Commited in debian/experimental as
49ffc5949f18118f4f33e95604231bfe86b4f6fd ]
Closes: 789709
|
|
Which, in this cherrypick is actually 7491bed8.
Git-Dch: Ignore
|
|
Git-Dch: Ignore
|
|
In 66c3875df391b1120b43831efcbe88a78569fbfe we workaround/fixed a
problem where the code makes the assumption that the compiler uses
copy-on-write implementations for std::string. Turns out that for c++11
compatibility gcc >= 5 will stop doing this by default.
|
|
The helper expects to be told if it should generate messages, not where
these messages should be printed – as it isn't printing such messages,
but puts them in _error. apt-get uses in other methods a helper
specialisation which does also print stuff to a stream through, so this
is likely a copy&paste error.
Git-Dch: Ignore
|
|
|
|
|
|
- re-add incorrectly removed pkgPackageManager::Go() to make
python-apt build again
|
|
|
|
* abi bump for gcc-5
* debian/control
- rename libapt-pkg4.12 -> libapt-pkg4.16,
the versions 4.13-4.15 are already taken in experimental
- rename libapt-inst1.5 -> libapt-inst1.7,
version 1.6 is already taken in experimental
- build-depend on gcc-5 (>= 5.2.1-10) temporarily
* debian/rules:
- build with -O2 everywhere because of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66868
|
|
Closes: #789491
Conflicts:
po/tr.po
|
|
* fix a wrong translation.
* update some translations.
|
|
|
|
This significantly reduces the number of files that have to be closed
and seems to be faster, despite the additional reads.
On systems where /proc/self/fd is not available, we fallback to the
old code that closes all file descriptors >= 3.
Closes: #764204
|
|
|
|
Conflicts:
debian/changelog
|
|
|
|
|
|
|
|
Git-Dch: ignore
|
|
Conflicts:
apt-pkg/deb/dpkgpm.cc
|
|
The underlying problem is that libapt-pkg does not correctly parse these
provides. Internally, it creates a version named "baz:i386" with
architecture amd64. Of course, such a package name is invalid and thus
this version is completely inaccessible. Thus, this bug should not cause
apt to accept a broken situation as valid. Nevertheless, it prevents
using architecture qualified depends.
Closes: 777071
|
|
Add a regression test that reproduced the hang of apt when a
partial file is present.
Git-Dch: ignore
|
|
The variable "Size" was misleading and caused bug #1445239. To
avoid similar issues in the future, rename it to make the meaning
more obvious.
git-dch: ignore
|
|
The apt http code parses Content-Length and Content-Range. For
both requests the variable "Size" is used and the semantic for
this Size is the total file size. However Content-Length is not
the entire file size for partital file requests. For servers that
send the Content-Range header first and then the Content-Length
header this can lead to globbing of Size so that its less than
the real file size. This may lead to a subsequent passing of a
negative number into the CircleBuf which leads to a endless
loop that writes data.
Thanks to Anton Blanchard for the analysis and initial patch.
LP: #1445239
|
|
|
|
Conflicts:
configure.ac
debian/changelog
|
|
|
|
|
|
|
|
The fix for #777760 causes packages of foreign (and the native)
architectures, to be created correctly, but invalidates (like the
previously existing, but policy-forbidden architecture-less packages
we had to support for some upgrade scenarios) the assumption that the
first (and only) package in the cache for a single architecture system
must be the package for the native architecture (as, where should the
other architectures come from, right? Wrong.).
Depending on the order of parsing sources more or less packages can be
effected by this. The effects are strange (for apt it mostly effects
simulation/debug output, but also apt-mark on these specific packages),
which complicates debugging, but relatively harmless if understood as
most actions do not need direct named access to packages.
The problem is fixed by removing the single-arch special casing in the
paths who had them (Cache.FindPkg), so they use the same code as
multi-arch systems, which use them as a wrapper for Grp.FindPkg.
Note that single-arch system code was using Grp.FindPkg before as well
if a Grp structure was handily available, so we don't introduce new
untested code here: We remove more brittle special cases which are less
tested instead (this was planed to be done for Stretch anyhow).
Note further that the method with the assumption itself isn't fixed. As
it is a private method I opted for declaring it deprecated instead and
remove all its call positions. As it is private no-one can call this
method legally (thanks to how c++ works by default its still an exported
symbol through) and fixing it basically means reimplementing code we
already have in Grp.FindPkg.
Removing rather than fixing seems hence like a good solution.
Closes: 782777
Thanks: Axel Beckert for testing
|
|
to 404"
This reverts commit 1296bc7c466181a7978c313c40a041b34ce3eaeb.
|
|
|
|
On single-arch the parsing was creating groupnames like 'apt:amd64' even
through it should be 'apt' and a package in it belonging to architecture
amd64. The result for foreign architectures was as expected: The
dependency isn't satisfiable, but for native architecture it means the
wrong package (ala apt:amd64:amd64) is linked so this is also not
satisfiable, which is very much not expected.
No longer excluding single-arch from this codepath allows the generation
of the correct links, which still link to non-exisiting packages for
foreign dependencies, but natives link to the expected native package
just as if no architecture was given.
For negative arch-specific dependencies ala Conflicts this matter was
worse as apt will believe there isn't a Conflict to resolve, tricking it
into calculating a solution dpkg will refuse.
Architecture specific positive dependencies are rare in jessie – the
only one in amd64 main is foreign –, negative dependencies do not even
exist. Neither class has a native specimen, so no package in jessie is
effected by this bug, but it might be interesting for stretch upgrades.
This also means the regression potential is very low.
Closes: 777760
|
