| Age | Commit message (Collapse) | Author |
|---|
|
This adds ::InfoFD option alongside the ::Version one to request sending
the information to the specified FD, by default it is STDIN as it was
the case before.
The environment variable APT_HOOK_INFO_FD contains the FD the data is on as
a confirmation that the APT version used understood the request.
Allowing the hook to choose the FD is needed/helpful e.g. for shellscripts
which have a hard time accessing FDs above 9 (as >= 10 are usually used
internally by them)
Closes: #671728
|
|
We don't need initialized memory for pkgTagFile, but more to the point
we can use realloc this way which hides the bloody details of increasing
the size of the buffer used.
Git-Dch: Ignore
|
|
In 91c4cc14d3654636edf997d23852f05ad3de4853 I removed the +256 from
the pkgTagFile call parsing Release files as I couldn't find a
mentioning of a reason for why and it was marked as XXX which suggested
that at least someone else was suspicious.
It turns out that it is indeed "documented", it just didn't found it at
first but the changelog of apt 0.6.6 (29. Dec 2003) mentions:
* Restore the ugly hack I removed from indexRecords::Load which set the
pkgTagFile buffer size to (file size)+256. This is concealing a bug,
but I can't fix it right now. This should fix the segfaults that
folks are seeing with 0.6.[45].
The bug it is "hiding" is that if pkgTagFile works with a file which doesn't
end in a double newline it will be adding it without checking if the Buffer
is big enough to store them. Its also not a good idea to let the End
pointer be past the end of our space, even if we don't access the data.
Closes: 719629
|
|
Release files are basically one big Section, so we might safe some
Resize circles by starting with the filesize.
Git-Dch: Ignore
|
|
merged without breaking ABI
|
|
- add Glob() to fileutl.{cc,h}
Conflicts:
apt-pkg/contrib/fileutl.h
debian/changelog
|
|
- support Configuration.Clear() for a clear of the entire
configuration
Conflicts:
debian/changelog
|
|
|
|
experimental
|
|
While we don't want these error messages on our usual stack, we can use
our usual infrastructure to generate an error message with all the usual
bells like errno and strerror attached.
Git-Dch: Ignore
|
|
If this code is run as non-root we are in a special situation (e.g. in
our testcases) where it is obvious that we can't enforce user/group on
any file, so skip this code altogether instead of bugging users with
an error message – which we also switch to a warning as a failure to
open the file is "just" a warning, so the 'wrong' owner shouldn't be
that much of an issue.
The file is still handled with chmod, so all the security we can enforce
is still enforced of course, which also gets a warning if it fails.
Git-Dch: Ignore
|
|
The constructors of our (clear)sign-acquire-items move a pre-existent
file for error-recovery away, which gets restored or discarded later as
the acquire progresses, but --print-uris never really starts the
acquire process, so the files aren't restored (as they should).
To fix this both get a destructor which checks for signs of acquire
doing anything and if it hasn't the file is restored.
Note that these virtual destructors theoretically break the API, but
only with classes extending the sign-acquire-items and nobody does this,
as it would be insane for library users to fiddle with Acquire
internals – and these classes are internals.
Closes: 719263
|
|
|
|
|
|
The handwritten parsing here was mostly done as we couldn't trust the
Release file we got, but nowadays we are sure that the Release file is
valid and contains just a single section we want it to include.
Beside reducing code it also fixes a bug: Fieldnames in deb822 formatted
files are case-insensitive and pkgTagFile does it correctly, but this
selfbuilt stuff here didn't.
|
|
The file we read will always be a Release file as the clearsign is
stripped earlier in this method, so this check is just wasting CPU
Its also removing the risk that this could ever be part of a valid
section, even if I can't imagine how that should be valid.
Git-Dch: Ignore
|
|
We start your quest by using the version of a package applying to a
specific pin, but that version could very well be below the current
version, which causes APT to suggest a downgrade even if it is
advertised that it never does this below 1000.
Its of course questionable what use a specific pin on a package has
which has a newer version already installed, but reacting with the
suggestion of a downgrade is really not appropriated (even if its kinda
likely that this is actually the intend the user has – it could just as
well be an outdated pin) and as pinning is complicated enough we should
atleast do what is described in the manpage.
So we look out for the specific pin and if we haven't seen it at the
moment we see the installed version, we ignore the specific pin.
Closes: 543966
|
|
|
|
|
|
|
|
The rational from the buglog:
> The problem here is that the Priority field in one of the Packages files
> is incorrect due to a mishap with reprepro configuration, […] the
> amd64 version is Priority: standard but the arm64 version is Priority:
> optional (and has a stray "optional: interpreters" field).
> […]
> However, Priority is a rather weak property of a package because it's
> typically applied via overrides, and it's easy for maintainers of
> third-party repositories to misconfigure them so that overrides aren't
> applied correctly. It shouldn't be ranked ahead of choosing packages
> from the native architecture. In this case, I have no user-mode
> emulation for arm64 set up, so choosing m4:arm64 simply won't work.
This effectly makes the priority the least interesting data point in
chosing a provider, which is in line with the other checks we have
already order above priority in the past and also has a certain appeal by
the soft irony it provides.
Closes: #718482
|
|
|
|
|
|
|
|
|
|
Git-Dch: Ignore
|
|
On CD-ROMs Translation-* files are only in compressed form included in
the Release file. This used to work while we had no record of
Translation-* files in the Release file at all as APT would have just
guessed the (compressed) filename and accepted it (unchecked), but now
that it checks for the presents of entries and if it finds records it
expects the uncompressed to be verifiable.
This commit relaxes this requirement again to fix the regression.
We are still secure "enough" as we can validate the compressed file we have
downloaded, so we don't loose anything by not requiring a hashsum for
the uncompressed files to double-check them.
Closes: 717665
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
StackPost
|
|
|
|
|
|
|
|
The code incorrectly skips printing of current version information,
if the package has no current version (for APT, but for dpkg as it is
the case for packages which are removed but not purged) by using an
unintended "else if" rather than an "if".
Closes: 717006
|
|
|
|
Multi-Arch: same packages can be co-installed, but need to have the same
version for all installed packages (aka "siblings"). Otherwise the
unsynced versions will fight against each other and the auto-install as
wel as the problem resolver will later have to decide between holding the
packages or to remove one of the siblings (usually a foreign) taking a
bunch of packages (like the entire foreign setup) with them.
The idea here is now to be more pro-active: MarkInstall will fail for
a package if the siblings aren't synced, so we don't allow a situation
in which a resolver has to decide if to hold or to remove-upgrade under
the assumption that the remove-upgrade decision is always wrong and
doesn't deserve to be explored (expect valid out-of-syncs of course).
Thats a pretty bold move to take for a library which is used by
different solvers so this check is done in IsInstallOk and can be
overridden if front-ends want to.
|
|
Default is to acquire all architectures from APT::Architectures which
can be changed by arch=, but this isn't very flexible if you want
"mostly" the default as you have to hardcode the architectures then,
so arch-= and arch+= can be used to add/remove architectures from the
default set.
On a machine with 'amd64' and 'i386' configured the lines:
deb [arch+=armel] http://example.org/debian wheezy rocks
deb [arch-=amd64] http://example.org/debian jessie rocks
will result in the download of:
wheezy Packages for 'amd64', 'i386' and 'armel'
jessie Packages for 'i386'
|
|
Adds on top of Version 2 to all displayed version numbers the
architecture as well as the MultiArch flag for consumption by the hooks.
Most of the time the architecture will be the same for both versions
displayed, but packages might change from "all" to "any" (or back)
between versions so we can't display the architecture for packages.
Pseudo-Format for Version 3:
<name> <version> <arch> <m-a-flag> <compare> <version> <arch> <m-a-flag>
Examples:
stuff - - none < 1 amd64 none **CONFIGURE**
libsame 1 i386 same < 2 i386 same **CONFIGURE**
stuff 2 i386 none > 1 i386 none **CONFIGURE**
libsame 2 i386 same > - - none **REMOVE**
toolkit 1 all foreign > - - none **REMOVE**
Closes: #712116
|
|
* apt-pkg/packagemanager.cc:
- increate APT::pkgPackageManager::MaxLoopCount to 5000
|
|
Conflicts:
debian/changelog
|
|
|
|
|
|
debug output of Debug::pkgDepCache::AutoInstall=true
|
|
|
|
GCC 4.8 is now clever enough to warn about:
contrib/sha2_internal.cc: In function ‘char* SHA256_End(SHA256_CTX*, char*)’:
contrib/sha2_internal.cc:656:31: warning: argument to ‘sizeof’ in ‘void*
memset(void*, int, size_t)’ call is the same expression as the destination;
did you mean to dereference it? [-Wsizeof-pointer-memaccess]
MEMSET_BZERO(context, sizeof(context));
So fix it as suggested. Its interesting though that the SHA2*
calculation as far as we need it works even without zeroing out.
Git-Dch: Ignore
|
