Age | Commit message (Collapse) | Author |
|
Git-Dch: Ignore
|
|
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.
|
|
debian/sid
|
|
|
|
|
|
debian/sid
|
|
|
|
Conflicts:
configure.ac
debian/apt.dirs
debian/changelog
|
|
|
|
This reverts commit 697c9314c8ba24f3e393b5de11a3fad7adae4bfc.
Conflicts:
debian/rules
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Closes: 746434
|
|
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
|
|
|
|
|
|
|
|
Conflicts:
po/vi.po
|
|
Signed-off-by: Trần Ngọc Quân <vnwildman@gmail.com>
|
|
Vendors like ubuntu need to change some options, so giving them
a way to do this less painfully avoids reducing differences.
|
|
gzip only gives us 32bit of size, storing it in a 64bit container and
doing a 32bit flip on it has therefore unintended results.
So we just go with a exact size container and let the flipping be handled
by eglibc provided le32toh removing our #ifdef machinery.
Closes: 745866
|
|
|
|
Those files are in apt-private and used from there.
Git-Dch: Ignore
|
|
beside reducing code a bit, it avoids oddball problems while building
the string and doesn't trigger static analyse warnings.
|
|
Debian wheezy shipped MultiArch to the masses and the predictions
remained true in sofar as little changes in apt itself and many
other frontends were needed compared to the fallout if done differently.
The info included is this file is therefore no longer current and adds
no useful information anymore, so we can drop it for good.
|
|
|
|
Modified by commiter to not publicily export the codename (as the
manpages do not use it that way) and removing the included additional
derives logic as it was not working (the link always exists at that
point) and isn't needed as we do the special casing for debian mainly
because it would shallow all distributions otherwise.
(similar, but not that strong for ubuntu)
Closes: 743595
|
|
The bugreport highlights the problem with an empty package name. We fix
this by 'ignoring' these so that it behaves just like "apt-get install".
The deeper problem is that modifier strings can be longer than a package
name in which case the comparison doesn't make sense, so don't compare
then. Was not noticed so far as all modifiers are of length 1, so the
only package name shorter than this is in fact the empty package name.
Closes: 744940
|
|
In bug #740673 various issues in the CD-ROM handling code were
identified, while most the issues ended up being fixed in another way,
the unmounting of the CD-ROM in error cases was not tackled so far.
(The patch was modified by the commiter to apply)
|
|
config files
|
|
|
|
|
|
|
|
|
|
Conflicts:
debian/changelog
|
|
|
|
FileFd::Read already deals with the increase of the skipposition so that
we as the caller in FileFd::Skip really shouldn't increase it, too.
|
|
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.
|
|
(LP: #1310548, closes: #744297)
|
|
|
|
Closes: 745452
|
|
|
|
Closes: 745452
|
|
|