[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#692036: marked as done (unlock apt/0.9.7.6)

Your message dated Thu, 01 Nov 2012 16:41:14 +0100
with message-id <5092981A.60801@thykier.net>
and subject line Re: Bug#692036: unlock apt/0.9.7.6
has caused the Debian Bug report #692036,
regarding unlock apt/0.9.7.6
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
692036: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692036
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: deity@lists.debian.org

Please unblock package apt

Welcome to another lovely episode of "APT unblock"-request!
Previously on the show we had 0.9.7.5, today is all about 0.9.7.6
and the diff between the two looks like this:
(minus translation updates and testcases):
 apt-pkg/contrib/netrc.cc |   56
+++++++++++++++++++++++++++++++++++---------------------
 apt-pkg/contrib/netrc.h  |    8 +++-----
 apt-pkg/depcache.cc      |    2 +-
 apt-pkg/edsp.cc          |    6 ++++--
 apt-pkg/pkgcache.cc      |   25 +++++++++++++++++++++++--
 apt-pkg/pkgcachegen.cc   |   17 +++++++++++++----
 apt-pkg/policy.cc        |   49
++++++++++++++++++++++++++-----------------------
 cmdline/apt-cache.cc     |   10 +++++++---
 8 files changed, 112 insertions(+), 61 deletions(-)

The version has survived now 15 days without a single report of a regression
in unstable and I have the impression that it closes an RC bug (#689519) and
implements a feature debian-cd asked for to fix an rc bug on their side so
an unblock would be nice, but more on all this in the detail rundown:
(reordered a bit for my comment-convenience)


>  * apt-pkg/pkgcachegen.cc:
>    - ensure that dependencies for packages:none are always generated

Fixing the arch-less packages support as denoted in the previous unblock
request. Making these "broken" systems now potentially even more "broken"
but in a more consistent way (sounds nice, doesn't it?).
Getting ride of arch-less packages is still your best option out of the mess
and the support is only there to help in this effort.


>    - write the native architecture as unique string into the cache header
>      as it is used for arch:all packages as a map to arch:native.
>      Otherwise arch comparisons later will see differences (Closes: #689323)

Comparing architectures can be done by string comparison or by comparing
the storage-location of the string. The second one is obviously a bit faster
(not that it would matter much). Codepaths in the EDSP support assume that
the second approach works. We could just use string-comparison here, but it
might not be the only place it is done this way in APT and even if it would
other users of libapt-pkg might do it. So it's better to make the assumption
true (again) than trying to find each place this assumption is made.


>  * apt-pkg/pkgcachegen.cc:
>    - Fix crash if the cache is remapped while writing a Provides version
>      (LP: #1066445) (Closes: #690498)
>    - add 2 missing remap registrations causing a segfault in case
>      we use the not remapped iterators after a move of the mmap again

I have the impression that these two are the reason behind the unreproducible
rc-bug #689519 as both issues are pretty hard to trigger (it not only depends
on the kernel growing mmap at the right time in these codeparts but also on
the kernel growing it in a certain way (aka: moving it around as not enough
space is available after the current mmap location)). Usually APT segfaults
in cache generation then, but if we are "lucky" the pointer is still valid
but now pointing at the wrong place in our binary cache, so that it might or
might not crash at any given moment (depending on what is now at the pointer
location and therefore overridden with a different kind of unexpected data …).


>  * apt-pkg/pkgcache.cc:
>    - ignore negative dependencies applying in the same group for M-A:same
>      packages on the real package name as self-conflicts (Closes: #688863)

There is not a single instance of this in Debian so far, but it is what the
Policy will define with the introduction of Multi-Arch in it as Russ said in
the discussion triggering the bugreport, so better to get it straight now.


>  * cmdline/apt-cache.cc:
>    - print versioned dependency relations in (r)depends if the option
>      APT::Cache::ShowVersion is true (default: false) as discussed in
>      #218995 to help debian-cd fixing #687949. Thanks to Sam Lidder
>      for initial patch and Steve McIntyre for nagging and testing!

It's a feature, but very small, disabled by default and it is blocking the
fix for a serious bug against debian-cd, so it's hopefully okay.


>  * apt-pkg/edsp.cc:
>    - include reinstall requests and already installed (= protected) packages
>      in the install-request for external resolvers (Closes: #689331)

Usage of external dependency solvers isn't common, but if you do use it
is quiet important to provide the correct information to the solver or
otherwise bad things may happen.


>  * apt-pkg/policy.cc:
>    - match pins with(out) an architecture as we do on the commandline
>      (partly fixing #687255, b= support has to wait for jessie)

Fixes the inconsistency between commandline and the preferences file
about how to interpret "Package: pkgname". The commandline assumes
"pkgname:native" while the preferences file used "pkgname:*".
This not only makes preferring certain architectures of packages harder,
but this inconsistency probably doesn't help in making preferences less
complicated and potentially even more unintuitive.


>  * apt-pkg/contrib/netrc.cc:
>    - remove the 64 char limit for login/password in internal usage
>    - remove 256 char line limit by using getline() (POSIX.1-2008)

The alternative is to just increase the limit and be done, but there is
probably always at least one user with a password with the length of
$limit + 1 and we would need an errormessage for limit exceedings which
we currently don't have, as until now it was a silent unfriendly cut-off.
(Not that there are that many password protected repositories out there,
 but e.g. commercial vendors seem to like them and it is also used by
 some teams/derivatives to limit access to unreleased packages)


So far from me about the current episode. Another episode is in
production, so if you are a fan of the show you can soon enjoy
another one … (sorry about that for the rest, but I get the impression
it is better to have multiple "small" compared to one giant blob).


unblock apt/0.9.7.6


Thanks for watching & best regards

David Kalnischkies

Attachment: apt-unblock-0.9.7.6.diff
Description: Binary data


--- End Message ---
--- Begin Message --- 
On 2012-11-01 15:30, David Kalnischkies wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian.org@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: deity@lists.debian.org
> 
> Please unblock package apt
> 
> [...]
> 
> 
> So far from me about the current episode. Another episode is in
> production, so if you are a fan of the show you can soon enjoy
> another one … (sorry about that for the rest, but I get the impression
> it is better to have multiple "small" compared to one giant blob).
> 

Multiple small ones are usually easier to review (which I believe is why
they would be "better").  It is also helpful with the extended
description of the changes.  :)

> 
> unblock apt/0.9.7.6
> 
> 
> Thanks for watching & best regards
> 
> David Kalnischkies

Unblocked, thanks.

~Niels

--- End Message ---
Reply to: