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

Bug#685155: marked as done (unblock: apt/0.9.7.4)

Your message dated Sun, 02 Sep 2012 16:33:09 +0100
with message-id <1346599989.25118.34.camel@jacala.jungle.funky-badger.org>
and subject line Re: Bug#685155: unblock: apt/0.9.7.4
has caused the Debian Bug report #685155,
regarding unblock: apt/0.9.7.4
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.)


-- 
685155: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685155
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

The diff between 0.9.7.2 and 0.9.7.4 is
(minus translation updates and manually-run testcases):

 apt-pkg/cacheset.cc        |    2 ++
 apt-pkg/cdrom.cc           |    4 ++--
 apt-pkg/contrib/fileutl.cc |    2 --
 apt-pkg/contrib/mmap.cc    |   31 +++++++++++++++++++++----------
 apt-pkg/indexcopy.cc       |    7 ++++++-
 apt-pkg/packagemanager.cc  |    2 +-
 cmdline/apt-get.cc         |   39 +++++++++++++++++++++++++--------------
 doc/apt-verbatim.ent       |   10 +++++-----
 8 files changed, 62 insertions(+), 35 deletions(-)

The changes are denoted as follows in the changelog (merged .3 and .4)
with some more comments regarding reason and possible regressions:
(tl;dr: good reasons and low regression potential - just unblock ;) )


> * apt-pkg/cacheset.cc:
>   - handle :all and :native correctly as architectures again
>     in the commandline parsing (regression in 0.9.7)

Especially not accepting :all could be very confusing.
And :native has some benefits for script usage.


> * apt-pkg/packagemanager.cc:
>   - do not segfault if nothing can be configured to statisfy
>     a pre-depends (e.g. in a pre-depends loop) (Closes: #681958)

No loops is a valid alternative, but somehow unrealistic …
(there is another bug shown by this, as the given example is not really
 a loop, but the fix looks like being a bit larger and in areas you
 don't want to mess with - especially not in freeze)


> * apt-pkg/contrib/mmap.cc:
>   - trigger the usage of the fallback code for kfreebsd also in the
>     second (filebased) constructor of DynamicMMap (Closes: #677704)
>   - guard only the msync call with _POSIX_SYNCHRONIZED_IO rather
>     than also the fallback code as it breaks APT on hurd since 0.9.7.3
>     as the fallback is now always used on non-linux (Closes: #683354)

kfreebsd (and hurd) do not have mremap which is needed for dynamic growing
of our mmap, but we have a fallback code with a char[] and realloc for
those. Unfortunately the fallback was only enabled in one of the two
constructors and fallback on hurd was actually broken as the cache file
was not written to disk (completely).

New installs (because of the many Translation files) as well as MultiArch
systems need growing otherwise APT refuses to work by displaying …


>   - refer to APT::Cache-Start in case the growing failed as if -Limit is
>     really the offender it will be noted in a previous error message.

… an incorrect message saying you have to increase APT::Cache-Limit rather
than -Start, which doesn't help.
(The start is currently 25 MB which it is since lenny and should be enough
 for everyone [for now] -- comparison: on my amd64+i386 system with sid,
 wheezy and squeeze sources the cache ends up being 80 MB big.)

This effects squeeze as well, but caches were smaller back then,
so nobody stumbled upon these issues until now.


>   - for filesystems not supporting mmap'ing a file we need to use a
>     SyncToFd dummy just as we did for compressed files in 0.9.5

The only filesystem I know not supporting it is jffs2 which was/is a
popular default filesystem for "embedded" (arm) devices like the openmoko.
The result would be "random" segfaults as memory areas are unmapped
which are not ours but belong to malloc.
(it seems like ubifs is the better alternative nowadays in this area through)


> * apt-pkg/contrib/fileutl.cc:
>   - remove _POSIX_SYNCHRONIZED_IO guard in FileFd::Sync() around fsync
>     as this guard is only needed for fdatasync and not defined on hurd
> * apt-pkg/indexcopy.cc:
>   - do not use atomic writing if the target is /dev/null as we don't want
>     to replace it, not even atomically. (Closes: #683410)
> * doc/apt-verbatim.ent:
>   - denote 'wheezy' as stable codename and 'jessie' as testing codename
>     in the documentation in preparation for release

(nothing to add)

> * cmdline/apt-get.cc:
>   - error out on (unsatisfiable) build-deps on purly virtual packages
>     instead of ignoring these dependencies; thanks to Johannes Schauer
>     for the detailed report! (Closes: #683786)
>   - ensure that the right architecture is used for cross-dependencies in
>     cases we have to choose a provider by defaulting on host-arch
>     instead of build-arch

Johannes implements this in dose3 as part of his GSoC project. After some
back and forth we reached the point that apt-get and dose3 now agree on
their solutions for the whole debian archive.


> * apt-pkg/cdrom.cc:
>   - do not link() but rename() the cdroms.list to cdroms.list~ as a backup
>     to ensure that apt-cdrom can be run multiple times (Closes: #676302)

We got multiple reports that claimed that d-i ran into this. I couldn't
reproduce this itself, but the bug indeed prevents apt-cdrom from being
used multiple times in a row by a backup-file, which is a bit silly …


Attached is a more complete diff (but still without translations),
but if you want the complete diff or if you have any additional questions
feel free to ask of course (just keep deity@ cc'ed please).


unblock apt/0.9.7.4


Thanks for your work & best regards

David Kalnischkies

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


--- End Message ---
--- Begin Message --- 
On Fri, 2012-08-17 at 14:59 +0200, David Kalnischkies wrote:
> Please unblock package apt
> 
> The diff between 0.9.7.2 and 0.9.7.4 is
> (minus translation updates and manually-run testcases):
[...]
>  8 files changed, 62 insertions(+), 35 deletions(-)
> 
> The changes are denoted as follows in the changelog (merged .3 and .4)
> with some more comments regarding reason and possible regressions:
> (tl;dr: good reasons and low regression potential - just unblock ;) )

Done; thanks.

Regards,

Adam

--- End Message ---
Reply to: