| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
* 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
|
|
|
|
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
|
|
Conflicts:
apt-pkg/deb/dpkgpm.cc
|
|
gnupg is case-insensitive about keyids, so back then apt-key called it
directly any keyid was accepted, but now that we work more with the
keyid ourself we regressed to require uppercase keyids by accident.
This is also inconsistent with other apt-key commands which still use
gnupg directly. A single case-insensitive grep and we are fine again.
Closes: 781696
|
|
g++-5 generates a slightly broken libapt which doesn't split
architecture configurations correctly resulting in e.g. Packages files
requested for the bogus architecture 'amd64,i386' instead of for amd64
and i386.
The reason is an incorrectly applied attribute marking the function as
const, while functions with pointer arguments are not allowed to be
declared as such (note that char& is a char* in disguise). Demoting the
attribute to pure fixes this issue – better would be dropping the & from
char but that is an API change…
Neither earlier g++ versions nor clang use this attribute to generate
broken code, so we don't need a rebuild of dependencies or anything and
g++-5 isn't even included in jessie, but the effect is so strange and
apt popular enough to consider avoiding this problem anyhow.
|
|
libapt can be configured to write various bits of information to a file
creating a report via apport. This is disabled by default in Debian and
apport residing only in /experimental so far, but Ubuntu and other
derivatives have this (in some versions) enabled by default and there is
no regression potentially here.
The crash is caused by a mismatch of operations vs. strings for
operations, so adding the missing strings for these operations solves
the problem.
[commit message by David Kalnischkies]
LP: #1436626
|
|
In /experimental this is resolved by deprecating Mode and moving to a
new std::string, but that breaks ABI of course, so that was out of
question. We can't change to a malloc/free style c-string either as
Mode is public and hence a library user could be setting this as well.
std::string implementors actually helped us out here with copy-on-write
which means that while the variable "obviously" runs out of scope here,
in reality you get the correct result as the string we work with here
comes from the configuration in which it is still valid. Such a
dependency on magic is bad of course, but its still interesting that
only python3 seems to have an issue with it…
With some silly explicit if-else assigning we can sidestep this issue
while retaining the same output for 99.99% of all users (= noone
actually configures additional compression algorithms which are also
provided by repositories…), but even for these 0.01% its just a small
change in the display as Mode can not be used for anything else.
Example: apt/aptitude uses it in its 'update' implementations in the
one-line progress at the bottom for specific items.
Closes: 781858
|
|
The worker expects that the methods tell him when they start or finish
downloading a file. Various information pieces are passed along in this report
including the (expected) filesize. https is using a "global" struct for
reporting which made it 'reuse' incorrect values in some cases like a
non-existent InRelease fallbacking to Release{,.gpg} resulting in an incorrect
size-mismatch warning scaring and desensitizing users as well as being subject
to a race between the write_data and progress callbacks generating incorrect
progress reporting and potentially the same error message.
Other branches as well as the bugreports contain 'better' fixes making the
struct local and other sensible changes, but are larger as a result, so in
this version we opted for short diff with minimal effect above else instead.
Closes: 777565, 781509
Thanks: Robert Edmonds and Anders Kaseorg for initial patchs
|
|
You would think one instance of this is enough, but
80e8d923ebc8d5f3f84eb3f922b28ca309c25026 wasn't as
globally applied as the commit message suggested…
LP: #1399037
|
|
|
|
|
|
|
|
|
|
|
|
- give apt more time to gather download data in test
|
|
- give apt more time to gather download data in test
|
|
|
|
|
|
|
|
|
|
Conflicts:
configure.ac
debian/changelog
|
|
|
|
Do not crash in ServerState::HeaderLine if there is no Owner.
Closes: #778375
|
|
|
|
|
|
Commit 9ec748ff103840c4c65471ca00d3b72984131ce4 from Feb 23 last year
adds a version check after 8daf68e366fa9fa2794ae667f51562663856237c
added 8 days earlier negative points for breaks/conflicts with the
intended that only dependencies which are satisfied propagate points
(aka: old conflicts do not).
The implementation was needlessly complex and flawed through preventing
positive dependencies from gaining points like they did before these
commits making library transitions harder instead of simpler. It worked
out anyhow most of the time out of pure 'luck' (and other ways of
gaining points) or got miss attributed to being a temporary hick-up.
Closes: 774924
|
|
Your mileage may vary, but don't worry: There is more than one way to
do it, but our one size fits all is not a bigger hammer, but an entire
roundhouse kick! So brace yourself for the tl;dr: The limit is gone.*
Beware: This fixes also the problem that a double newline is
unconditionally added 'later' which is an overcommitment in case
the dsc filesize is limit-2 <= x <= limit.
* limited to numbers fitting into an unsigned long long.
Closes: 774893
|
|
The issue was that https.cc never called URIStart(), one way to
detect this is that no download progress is generated without
this call. The test now checks for this and as a side-effect will
also ensure that we do not break download progress reporting and
Acquire::{http,https}::Dl-Limit accidently.
|
