Debian Bug report logs - #683786
apt-get cross build dependency resolution of arch:all, m-a:none packages

version graph

Package: apt; Maintainer for apt is APT Development Team <deity@lists.debian.org>; Source for apt is src:apt.

Reported by: Johannes Schauer <j.schauer@email.de>

Date: Fri, 3 Aug 2012 23:09:01 UTC

Severity: normal

Found in version apt/0.9.7.3

Fixed in version apt/0.9.7.4

Done: Michael Vogt <mvo@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#683786; Package apt. (Fri, 03 Aug 2012 23:09:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Johannes Schauer <j.schauer@email.de>:
New Bug report received and forwarded. Copy sent to APT Development Team <deity@lists.debian.org>. (Fri, 03 Aug 2012 23:09:04 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Johannes Schauer <j.schauer@email.de>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: apt-get cross build dependency resolution of arch:all, m-a:none packages
Date: Sat, 04 Aug 2012 01:03:59 +0200
Package: apt
Version: 0.9.7.3
Severity: normal


Hi,

all the following is based on a recent Debian Sid amd64 debootstrap
minbase chroot with armel enabled as a foreign architecture.

Dose3 fails to satisfy the cross build dependencies for the following
packages while apt does manage to satisfy them:

        dash, file, slang2, gzip, insserv, libsigsegv, make-dfsg, mpfr4,
        pam, sysvinit

Case 1
------

The following packages build-depend on a architecture:all, M-A: none
package. Dose3 correctly detected that they cannot satisfy the cross
build dependencies because they are not marked M-A: foreign. Apt decides
to ignore that and doesnt install them at all. Apt seems to completely
ignore that build dependency and is therefor able to believe it can
satisfy it.

{package}->{dependency that dose3 detected to be unsatisfiable and apt ignores} 

dash    -> po-debconf
file    -> python
slang2  -> autoconf

two examples:

josch@hoothoot> sudo chroot ~/debian-sid-minbase apt-cache showsrc dash | grep po-debconf
Build-Depends: po-debconf
josch@hoothoot> sudo chroot ~/debian-sid-minbase apt-get --simulate -aarmel build-dep dash | grep po-debconf | wc -l
0
josch@hoothoot> sudo chroot ~/debian-sid-minbase apt-get --option Debug::BuildDeps=true --simulate -aarmel build-dep dash | grep po-debconf
Looking for po-debconf...
  Trying to install po-debconf [ armel ] < none > ( none )

Case 2
------

The following packages also build-depend on a architecture:all, M-A:
none package. Since the packages are not M-A: foreign, they should not
be used to satisfy the build-dependencies for cross building. Apt
chooses to install them anyways:

{package}->{dependency that dose3 detected to be unsatisfiable but apt installs}

gzip    -> mingw-w64
insserv -> po-debconf
libsigsegv      -> autoconf
make-dfsg       -> autoconf
mpfr4   -> texlive-latex-base
pam     -> docbook-xml
sysvinit        -> po-debconf

an example:

josch@hoothoot> sudo chroot ~/debian-sid-minbase apt-cache showsrc
Build-Depends: debhelper (>= 8), po-debconf, bash-completion
josch@hoothoot> sudo chroot ~/debian-sid-minbase apt-get --option Debug::BuildDeps=true --simulate -aarmel build-dep insserv | grep po-debconf
Looking for po-debconf...
  Trying to install po-debconf [ armel ] < none > ( none )
  po-debconf
Inst po-debconf (1.0.16+nmu2 Debian:unstable [all])
Conf po-debconf (1.0.16+nmu2 Debian:unstable [all])


It is maybe interesting to see how dash and insserv both depend on
po-debconf and how slang2 and libsigsegv both depend on autoconf in the
exact same way but apt handles them differently. In one case it decides
to ignore the dependency on po-debconf and autoconf and in the other
case it wrongly installs the package even though it is not M-A: foreign
and should therefor not satisfy that build dependency.

Case 3
------

So we see that apt sometimes decides to use arch:all, M-A: none packages
to satisfy foreign build dependencies.

Then why do the following scenarios not work as expected:

josch@hoothoot> sudo chroot ~/debian-sid-minbase apt-get --simulate -aarmel build-dep libselinux
Reading package lists... Done
Building dependency tree... Done
E: Build-Depends dependency for libselinux cannot be satisfied because the package gem2deb cannot be found

josch@hoothoot> sudo chroot ~/debian-sid-minbase apt-get --simulate -aarmel build-dep libsemanage
Reading package lists... Done
Building dependency tree... Done
E: Build-Depends dependency for libsemanage cannot be satisfied because the package gem2deb cannot be found

josch@hoothoot> sudo chroot ~/debian-sid-minbase apt-get --simulate -aarmel build-dep libffi
Reading package lists... Done
Building dependency tree... Done
E: Build-Depends dependency for libffi cannot be satisfied because the package dejagnu cannot be found

josch@hoothoot> sudo chroot ~/debian-sid-minbase apt-get --simulate -aarmel build-dep diffutils
Reading package lists... Done
Building dependency tree... Done
E: Build-Depends dependency for diffutils cannot be satisfied because the package texi2html cannot be found

gem2deb, dejagnu and texi2html are arch:all, M-A: none packages just as
mingw-w64, po-debconf, autoconf, texlive-latex-base and docbook-xml that
apt happily installed before in some cases. Why doesnt it install those
packages this time?

Maybe there is a connection to bug#666772 ?

cheers, josch



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#683786; Package apt. (Sat, 04 Aug 2012 09:39:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to David Kalnischkies <kalnischkies+debian@gmail.com>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Sat, 04 Aug 2012 09:39:06 GMT) Full text and rfc822 format available.

Message #10 received at 683786@bugs.debian.org (full text, mbox):

From: David Kalnischkies <kalnischkies+debian@gmail.com>
To: Johannes Schauer <j.schauer@email.de>, 683786@bugs.debian.org
Subject: Re: Bug#683786: apt-get cross build dependency resolution of arch:all, m-a:none packages
Date: Sat, 4 Aug 2012 11:36:18 +0200
[Message part 1 (text/plain, inline)]
Hi Johannes,

first of all: Thanks for the detailed report!

On Sat, Aug 4, 2012 at 1:03 AM, Johannes Schauer <j.schauer@email.de> wrote:
> The following packages build-depend on a architecture:all, M-A: none
> package. Dose3 correctly detected that they cannot satisfy the cross
> build dependencies because they are not marked M-A: foreign. Apt decides

You mean the right thing, but for anyone else reading it:
Meant is that the arch:all package isn't marked as M-A:foreign.
And the "following packages" are all M-A: none packages itself with "normal"
(aka no specific architecture or same, any, or whatever behind a colon)
dependencies on the arch:all packages.


> to ignore that and doesnt install them at all. Apt seems to completely
> ignore that build dependency

That is actually exactly what happens - and doesn't only effect M-A.
In line 3090 of cmdline/apt-get.cc in DoBuildDep() you can find a call to
TryToInstallBuildDep method there the boolean return is checked and based
on that it is decided if the try was successful or not (and if not we fail).

The problem is just that the returnvalue will always be 'true' as the method
has an optional AllowFail parameter which defaults to true and isn't specified
on this line (calling blame suggests that someone named David messed it up
while reworking the commandline parsing before squeeze… bad David… [0])

Horrible, isn't it? But a question is still open:

> So we see that apt sometimes decides to use arch:all, M-A: none packages
> to satisfy foreign build dependencies.
>
> Then why do the following scenarios not work as expected:

The reason is simply that the mistake above has only an effect on purely
virtual packages (= packages without a version) and not for packages which
simple do not exist. So this isn't even limited to :all packages, but :any
packages as well, as long as they do not exist for the host architecture, but
have (host-arch) packages depending on them (which is just less likely).

You can verify this by trying:
apt-cache showpkg po-debconf:armel texi2html:armel

You will see that a po-debconf:armel package exists because an :any package
depends on it, while texi2html:armel doesn't exist (= nothing depends on it)


The fix is simply to add a ", false" to the end of the parameter list on the
previously mentioned line. Bonuspoints for adding on line 3007 to the check
if the package exists also a check if the package has at least one version
("|| Pkg->VersionList == 0").

Both by itself has the desired effect - an error - but:
"Make assurance double sure!" ;)
(patch with a simple testcase attached)

> Case 2
> ------
>
> The following packages also build-depend on a architecture:all, M-A:
> none package. Since the packages are not M-A: foreign, they should not
> be used to satisfy the build-dependencies for cross building. Apt
> chooses to install them anyways:
>
> {package}->{dependency that dose3 detected to be unsatisfiable but apt installs}
>
> gzip    -> mingw-w64

gzip Build-Depends-Indep: mingw-w64, so that mingw-w64:build is installed
is fine as we don't need to cross-build arch:all packages. Looks for me like
a bug in dose3 instead.
(I can't reproduce other examples in that group)


> Maybe there is a connection to bug#666772 ?

No, and given that dpkg-maintainers haven't agreed to this plan yet,
i guess it can be considered a "no", but Steve wanted to pursue this further.
After all, it is not that important for wheezy, as APT and dpkg are far from
the only places needing support for it, so it will only work out for jessie -
if at all anyway (as other tools have no M-A support at all in wheezy).


Best regards

David Kalnischkies

[0] completely unrelated coincident (of course):
The Big Bang Theory S03E11 was (re)aired here yesterday. Last scene:
Sheldon: "I blame Penny."
Penny: "I blame Penny, too. Bad Penny."
[apt-683786-build-dep-on-virtual-packages.diff (application/octet-stream, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#683786; Package apt. (Sat, 04 Aug 2012 12:39:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Johannes Schauer <j.schauer@email.de>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Sat, 04 Aug 2012 12:39:06 GMT) Full text and rfc822 format available.

Message #15 received at 683786@bugs.debian.org (full text, mbox):

From: Johannes Schauer <j.schauer@email.de>
To: David Kalnischkies <kalnischkies+debian@gmail.com>
Cc: 683786@bugs.debian.org
Subject: Re: Bug#683786: apt-get cross build dependency resolution of arch:all, m-a:none packages
Date: Sat, 4 Aug 2012 14:36:01 +0200
Hi David,

On Sat, Aug 04, 2012 at 11:36:18AM +0200, David Kalnischkies wrote:
> first of all: Thanks for the detailed report!

Thank you for your quick reply! I was stunned by the nearly 1000 open
bugs for apt so I feared I would never get a reply to this :D

> On Sat, Aug 4, 2012 at 1:03 AM, Johannes Schauer <j.schauer@email.de> wrote:
> > The following packages build-depend on a architecture:all, M-A: none
> > package. Dose3 correctly detected that they cannot satisfy the cross
> > build dependencies because they are not marked M-A: foreign. Apt decides
> 
> You mean the right thing, but for anyone else reading it:
> Meant is that the arch:all package isn't marked as M-A:foreign.
> And the "following packages" are all M-A: none packages itself with "normal"
> (aka no specific architecture or same, any, or whatever behind a colon)
> dependencies on the arch:all packages.

Exactly. Thanks for clarifying this.

> The fix is simply to add a ", false" to the end of the parameter list
> on the previously mentioned line. Bonuspoints for adding on line 3007
> to the check if the package exists also a check if the package has at
> least one version ("|| Pkg->VersionList == 0").

Then Patrick McDermott deserves those points as he told me the exact
same fix half an hour before your email :)

The downside is, that this change seems to break other dependency
resolutions. For example sed build depends on libselinux-dev which is
provided by libselinux1-dev.

Without the change you suggested, libselinux1-dev gets installed as
expected but with that change, apt-get now says:

josch@hoothoot> sudo chroot ~/debian-sid-minbase apt-get --simulate -aarmel build-dep sed
Reading package lists... Done
Building dependency tree... Done
E: Build-Depends dependency for sed cannot be satisfied because the package libselinux-dev cannot be found

Can you reproduce this behaviour?

> gzip Build-Depends-Indep: mingw-w64, so that mingw-w64:build is
> installed is fine as we don't need to cross-build arch:all packages.
> Looks for me like a bug in dose3 instead.

Yes it was indeed a bug in dose3. I discovered the apt-get behaviour I
reported here because I'm currently implementing cross compilation
dependency resolution support into dose3 as part of my GSoC project.
Dose3 was incorrectly treating the indep fields the same way as it
treated non-indep fields. This is now fixed and dose3 satisfies indep
dependencies with native packages. Thanks!

> > Maybe there is a connection to bug#666772 ?
> 
> No, and given that dpkg-maintainers haven't agreed to this plan yet,
> i guess it can be considered a "no", but Steve wanted to pursue this further.
> After all, it is not that important for wheezy, as APT and dpkg are far from
> the only places needing support for it, so it will only work out for jessie -
> if at all anyway (as other tools have no M-A support at all in wheezy).

Thanks for the info! I would also not like the proposed change to be
introduced in Debian. Having this exception only for dependency
resolution of cross build dependencies but nothing else doesnt seem to
be the right thing to do.

cheers, josch



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#683786; Package apt. (Sat, 04 Aug 2012 14:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to David Kalnischkies <kalnischkies+debian@gmail.com>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Sat, 04 Aug 2012 14:27:03 GMT) Full text and rfc822 format available.

Message #20 received at 683786@bugs.debian.org (full text, mbox):

From: David Kalnischkies <kalnischkies+debian@gmail.com>
To: Johannes Schauer <j.schauer@email.de>
Cc: 683786@bugs.debian.org
Subject: Re: Bug#683786: apt-get cross build dependency resolution of arch:all, m-a:none packages
Date: Sat, 4 Aug 2012 16:23:54 +0200
On Sat, Aug 4, 2012 at 2:36 PM, Johannes Schauer <j.schauer@email.de> wrote:
> On Sat, Aug 04, 2012 at 11:36:18AM +0200, David Kalnischkies wrote:
>> first of all: Thanks for the detailed report!
>
> Thank you for your quick reply! I was stunned by the nearly 1000 open
> bugs for apt so I feared I would never get a reply to this :D

Yeah, unfortunately APT hasn't that many active contributors to deal with
all the incoming work and as it is that way for years work kinda piles up
and especially the housekeeping in the bugtracker falls of the plate. :(

Luck helps of course, but detailed reports make it a lot easier to deal with.
That said, being a GSoC student with a MultiArch project helps, too,
given that MultiArch in APT was my project two years ago. ;)


>> On Sat, Aug 4, 2012 at 1:03 AM, Johannes Schauer <j.schauer@email.de> wrote:
>> The fix is simply to add a ", false" to the end of the parameter list
>> on the previously mentioned line. Bonuspoints for adding on line 3007
>> to the check if the package exists also a check if the package has at
>> least one version ("|| Pkg->VersionList == 0").
>
> Then Patrick McDermott deserves those points as he told me the exact
> same fix half an hour before your email :)
>
> The downside is, that this change seems to break other dependency
> resolutions. For example sed build depends on libselinux-dev which is
> provided by libselinux1-dev.

Ah, sure. I should have seen that… Make that check a
|| (Pkg->VersionList == 0 && Pkg->ProvidesList == 0)


>> > Maybe there is a connection to bug#666772 ?
>>
>> No, and given that dpkg-maintainers haven't agreed to this plan yet,
>> i guess it can be considered a "no", but Steve wanted to pursue this further.
>> After all, it is not that important for wheezy, as APT and dpkg are far from
>> the only places needing support for it, so it will only work out for jessie -
>> if at all anyway (as other tools have no M-A support at all in wheezy).
>
> Thanks for the info! I would also not like the proposed change to be
> introduced in Debian. Having this exception only for dependency
> resolution of cross build dependencies but nothing else doesnt seem to
> be the right thing to do.

Depends (pun intended), cross building has already a special ruleset so
one more or less isn't that bad and changing a big bunch of packages can
be quiet a bit of work - beside that Steve proposed it and who wanna talk
against the lord of multi-arch? ;)


Best regards

David Kalnischkies



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#683786; Package apt. (Sat, 04 Aug 2012 17:33:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Johannes Schauer <j.schauer@email.de>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Sat, 04 Aug 2012 17:33:07 GMT) Full text and rfc822 format available.

Message #25 received at 683786@bugs.debian.org (full text, mbox):

From: Johannes Schauer <j.schauer@email.de>
To: David Kalnischkies <kalnischkies+debian@gmail.com>
Cc: 683786@bugs.debian.org
Subject: Re: Bug#683786: apt-get cross build dependency resolution of arch:all, m-a:none packages
Date: Sat, 4 Aug 2012 19:25:22 +0200
Hi,

tldr: the issue seems solved, dose3 and apt-get only differ on 3 out of
635 source packages. You can probably close this bugreport using your
fixed patch.

On Sat, Aug 04, 2012 at 04:23:54PM +0200, David Kalnischkies wrote:
> > The downside is, that this change seems to break other dependency
> > resolutions. For example sed build depends on libselinux-dev which
> > is provided by libselinux1-dev.
> 
> Ah, sure. I should have seen that… Make that check a
> || (Pkg->VersionList == 0 && Pkg->ProvidesList == 0)

This solved the issue with my initial selection of 67 source packages.

Out of those 67 source packages, dose3 and apt-get now agree on whether
cross build dependencies can be fulfilled or not.

To make sure that indeed everything was solved, I ran another test with
a selection of 635 source packages.

Out of those, the only three source packages that differed in their result
were gpac, texlive-bin and libedit.


gpac and texlive-bin
--------------------

apt-get claimed that gpac and texlive-bin could not have their cross
build dependencies satisfied

josch@hoothoot> sudo chroot ~/debian-sid-minbase apt-get --simulate -aarmel build-dep gpac
Reading package lists... Done
Building dependency tree... Done
Note, selecting 'libjpeg8-dev' instead of 'libjpeg-dev'
Note, selecting 'libpng12-dev' instead of 'libpng-dev'
Note, selecting 'libxmlrpc-core-c3-dev:armel' instead of 'libxmlrpc-c3-dev:armel'
The following packages have unmet dependencies:
 libsdl1.2-dev:armel : Depends: libcaca-dev:armel but it is not going to be installed
                       Depends: libdirectfb-dev:armel (>= 0.9.22) but it is not going to be installed
E: Build-dependencies for gpac could not be satisfied.

josch@hoothoot> sudo chroot ~/debian-sid-minbase apt-get --simulate -aarmel build-dep texlive-bin
Reading package lists... Done
Building dependency tree... Done
Note, selecting 'libpng12-dev' instead of 'libpng-dev'
The following packages have unmet dependencies:
 libgd2-xpm-dev:armel : Depends: libpng12-0-dev:armel
E: Build-dependencies for texlive-bin could not be satisfied.


Both source packages build depend on libpng-dev which is a virtual
package provided by libpng12-dev which is also selected by apt in its
native version.

Gpac build depends on libdirectfb-dev which in turn depends on the
virtual package libpng-dev which apt satisfies with libpng12-dev:armel,
thereby creating the conflict.

Texlive-bin build depends on libgd2-xpm-dev which in turn depends on the
virtual package libpng12-0-dev which apt satisfies with
libpng12-dev:armel, thereby creating the conflict.

So there seems to be a problem when a source package build depends on a
virtual package provided by $pkg and another dependency of itself
depends on a virtual packages that is also provided by $pkg but differs
in architecture?

This problem exists in apt-get before as well as after your last patch,
so I guess it is a completely different problem?

I was posting it here anyways because the solution of this bugreport was
also about virtual packages so there might be a relationship?


libedit
-------

dose3 claims it cannot satisfy the cross build dependencies for libedit.
The reason it gives:

When cross compiling for armel on amd64, then:

 - src:libedit build-depends on bsdmainutils:armel
 - src:libedit build-depends on debhelper, depends on man-db:amd64,
   depends on bsdmainutils:amd64

But man-db is M-A: foreign which means that man-db:armel should be able
to satisfy the dependency of debhelper just as well as man-db:amd64.
Man-db:armel would in turn only require bsdmainutils:armel and there
would be no conflict. This explains why apt doesnt fail. I have to fix
dose3.


Conclusion
----------

The addition you made to your last patch seemed to have solved the issue
that I initially reported.

Since the other three differences appear with and without your patch
they seem not to be connected to this bugreport.

Should I open a new bugreport for the gpac/texlive-bin cross build
dependency satisfaction issue?

Thanks a lot for your very quick help!

cheers, josch



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#683786; Package apt. (Sat, 04 Aug 2012 23:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to David Kalnischkies <kalnischkies+debian@gmail.com>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Sat, 04 Aug 2012 23:57:03 GMT) Full text and rfc822 format available.

Message #30 received at 683786@bugs.debian.org (full text, mbox):

From: David Kalnischkies <kalnischkies+debian@gmail.com>
To: Johannes Schauer <j.schauer@email.de>
Cc: 683786@bugs.debian.org
Subject: Re: Bug#683786: apt-get cross build dependency resolution of arch:all, m-a:none packages
Date: Sun, 5 Aug 2012 01:53:35 +0200
[Message part 1 (text/plain, inline)]
On Sat, Aug 4, 2012 at 7:25 PM, Johannes Schauer <j.schauer@email.de> wrote:
> tldr: the issue seems solved, dose3 and apt-get only differ on 3 out of
> 635 source packages. You can probably close this bugreport using your
> fixed patch.

Thanks for testing! Well appreciated that we have a second tool working on
these cross-dependencies now around. Gives me personally a little more
confident that at least not everything is wrong in that code …
(frankly, I expected worse, given that I have never cross-compiled anything,
 so that my experience in that context is … limited.)

Now I just need to figure out how to get, build and run dose3.
If you have some doc for this already written somewhere I would welcome
a pointer, otherwise I presume I should reread your gsoc reports and
get the info from there. :)

> Both source packages build depend on libpng-dev which is a virtual
> package provided by libpng12-dev which is also selected by apt in its
> native version.

Attached is a diff for bug-class which should ensure that APT chooses by
default a host-arch packages (and especially a provider from that arch)
instead of sometimes ending up using build-arch. Either by just not using
build-arch if it could use host-arch (only if it needs to of course) or
by erroring out if no solution exists instead of claiming everything is fine
and ignoring all problems encountered.


Our tests are fine with it and the two mentioned packages seem to be fine too
(but I could solve build-deps before for both with an empty dpkg/status so
 I may as well just be lucky -- and it is late now in Germany, so I am
 probably even more "lucky" in overlooking new bugs than usual …).
I will give it more thoughts until Monday - Michael should be back then, too.


Best regards

David Kalnischkies
[apt-683786-build-dep-on-virtual-packages.diff (application/octet-stream, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#683786; Package apt. (Sun, 05 Aug 2012 07:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Johannes Schauer <j.schauer@email.de>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Sun, 05 Aug 2012 07:45:03 GMT) Full text and rfc822 format available.

Message #35 received at 683786@bugs.debian.org (full text, mbox):

From: Johannes Schauer <j.schauer@email.de>
To: David Kalnischkies <kalnischkies+debian@gmail.com>
Cc: 683786@bugs.debian.org
Subject: Re: Bug#683786: apt-get cross build dependency resolution of arch:all, m-a:none packages
Date: Sun, 5 Aug 2012 09:42:36 +0200
Hi David,

On Sun, Aug 05, 2012 at 01:53:35AM +0200, David Kalnischkies wrote:
> On Sat, Aug 4, 2012 at 7:25 PM, Johannes Schauer <j.schauer@email.de> wrote:
> > tldr: the issue seems solved, dose3 and apt-get only differ on 3 out of
> > 635 source packages. You can probably close this bugreport using your
> > fixed patch.
> 
> Thanks for testing! Well appreciated that we have a second tool working on
> these cross-dependencies now around. Gives me personally a little more
> confident that at least not everything is wrong in that code …
> (frankly, I expected worse, given that I have never cross-compiled
> anything, so that my experience in that context is … limited.)

The bad news is, that I do not cross compile anything either and (just
like you) only look at the dependency situation :D So in the worst case,
both of our algorithms produces the same wrong results ^^

Maybe dpkg-checkbuilddeps can *somehow* be used for additional
verification?

> Now I just need to figure out how to get, build and run dose3.  If you
> have some doc for this already written somewhere I would welcome a
> pointer, otherwise I presume I should reread your gsoc reports and get
> the info from there. :)

My mentor is currently on his holidays so he can only decide if he likes
my changes to dose3 and then apply them after he returns in a week or
so.  Should he apply my patches as I wrote them, then testing cross
build dependency satisfaction will be accomplished using the existing
tool deb-buildcheck but with an additional --host option that tells to
cross compile instead of doing native compilation.

You would then install the package dose-builddebcheck and run:

dose-builddebcheck -v --summary --deb-native-arch=amd64 --deb-foreign-archs=armel,linux-any --host=armel Sid-amd64-armel.bz2 Sid-Sources.bz2

Once he is back and a decision/fixing of my patches has been made and
stuff is in Debian I can give you a heads-up.

Should you need that functionality earlier, you can send me a private
mail and I will send you the patches and tell how to apply and use them.

> > Both source packages build depend on libpng-dev which is a virtual
> > package provided by libpng12-dev which is also selected by apt in
> > its native version.
> 
> Attached is a diff for bug-class which should ensure that APT chooses
> by default a host-arch packages (and especially a provider from that
> arch) instead of sometimes ending up using build-arch. Either by just
> not using build-arch if it could use host-arch (only if it needs to of
> course) or by erroring out if no solution exists instead of claiming
> everything is fine and ignoring all problems encountered.
> 
> 
> Our tests are fine with it and the two mentioned packages seem to be
> fine too (but I could solve build-deps before for both with an empty
> dpkg/status so I may as well just be lucky -- and it is late now in
> Germany, so I am probably even more "lucky" in overlooking new bugs
> than usual …).  I will give it more thoughts until Monday - Michael
> should be back then, too.

Over night I was running "apt-get -s -aarmel build-dep" for all
18244 source packages in Debian Sid. I started this before going to bed
(also late in Germany here) so without the patch of your last email. So
as a result, without your last patch, there were only 119 out of those
18244 on which apt-get and dose3 disagreed. Running apt-get build-dep on
all those 18244 packages took 8h.

Now I applied your patch and re-ran apt-get build-dep on those packages
of the remaining 119 that apt-get was not failing on. Two third of those
now fail correctly (at least dose3 believes the same).

It might of course be that your last patch introduces different results
elsewhere so I will now restart the whole process and report back in 8h
with the overall result :)

cheers, josch



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#683786; Package apt. (Sun, 05 Aug 2012 19:27:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Johannes Schauer <j.schauer@email.de>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Sun, 05 Aug 2012 19:27:06 GMT) Full text and rfc822 format available.

Message #40 received at 683786@bugs.debian.org (full text, mbox):

From: Johannes Schauer <j.schauer@email.de>
To: David Kalnischkies <kalnischkies+debian@gmail.com>
Cc: 683786@bugs.debian.org
Subject: Re: Bug#683786: apt-get cross build dependency resolution of arch:all, m-a:none packages
Date: Sun, 5 Aug 2012 21:23:47 +0200
Hi,

On Sun, Aug 05, 2012 at 01:53:35AM +0200, David Kalnischkies wrote:
> Attached is a diff for bug-class which should ensure that APT chooses
> by default a host-arch packages (and especially a provider from that
> arch) instead of sometimes ending up using build-arch.

Here is an analysis that ran on all source packages of Debian Sid after
having applied the patch of your last email to apt.

Out of 18244 source package in Debian Sid, apt-get and dose3 now only
disagree on 10 remaining packages (actually that number is only true
assuming that apt bug#683917 would also be resolved). 10 Packages are a
small enough number so that each can get a deeper analysis.

You can reproduce my results by creating a Debian Sid chroot as follows:

sudo debootstrap --variant=minbase sid debian-sid-minbase
echo -ne "deb http://ftp.debian.org/debian sid main\ndeb-src http://ftp.debian.org/debian sid main\n" | sudo tee debian-sid-minbase/etc/apt/sources.list
sudo chroot debian-sid-minbase dpkg --add-architecture armel
sudo chroot debian-sid-minbase apt-get update
sudo chroot debian-sid-minbase apt-get --simulate -aarmel build-dep $package


Fails with apt-get
==================

Apt-get cannot satisfy the dependencies of the following source packages
while dose3 can: libcatalyst-actionrole-acl-perl, obex-data-server,
qdox, renattach, trueprint.


libcatalyst-actionrole-acl-perl
-------------------------------

Build-Depends-Indep on libcatalyst-controller-actionrole-perl. Apt-get
says:

 libcatalyst-controller-actionrole-perl : Depends: libcatalyst-perl (>= 5.80025) but it is not going to be installed

It probably says that because libcatalyst-perl conflicts with
libcatalyst-controller-actionrole-perl.

But dose3 sees, that libcatalyst-controller-actionrole-perl is also
provided by libcatalyst-perl, so it uses libcatalyst-perl to satisfy the
build depends of the source libcatalyst-controller-actionrole-perl.


obex-data-server
----------------

Build-Depends on libmagickwand-dev (>= 6.0.0) | libgtk2.0-dev.

From those two choices, apt chooses to install libmagickwand-dev but
fails to do so. Dose3 agrees that libmagickwand-dev is not installable,
therefor it chooses to satisfy the build dependencies for
obex-data-server using libgtk2.0-dev instead. Apt-get on the other hand
doesnt try libgtk2.0-dev and therefor fails.


qdox
----

Was not able to make out what apt-get actually has a problem with.


renattach
---------

Build-Depends on exim4 | mail-transport-agent.

 Virtual packages like 'mail-transport-agent:armel' can't be removed

Dose3 on the other hand just satisfies the mail-transport-agent
dependency using xmail and is done with it.


trueprint
---------

Build-Depends on lpr which Depends on netbase.

 lpr:armel : Depends: netbase:armel but it is not installable

When trying to install netbase:armel itself, apt-get says:

Package netbase:armel is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
  net-tools:armel iputils-tracepath:armel iputils-ping:armel iputils-arping:armel ifupdown:armel update-inetd net-tools
  iputils-tracepath iputils-ping iputils-arping ifupdown

Dose3 on the other hand, sees that lpr is also provided by lprng and
uses this package to satisfy the build dependencies of trueprint,
thereby not getting into the netbase problem.


Fail with dose3
===============

Dose3 cannot satisfy the dependencies of the following source packages
while apt-get can: bomberclone, freetalk, garden-of-coloured-lights,
mailsync, worker.


bomberclone
-----------

Build-depends on findutils:armel which clashes with the installed
package findutils:amd64.

Apt-get chooses to just remove findutils:amd64 and replaces it with
findutils:armel. The multiarch cross spec doesnt cover this case so it
is debatable whose behaviour is right.

Maybe the following section of the multiarch spec should apply to the
cross case as well:

> it is assumed that any undeclared dependencies on Essential packages
> on the part of multiarch packages is satisfied by the binaries from
> the native architecture

Therefore, apt-get should not replace findutils:amd64 by findutils:armel
and dose3 should see the findutils:armel dependency satisfied by
findutils:amd64.

But this has to be discussed in another place.


freetalk
--------

Build-Depends on automake1.11 which is a virtual package provided by
automake. Apt get wrongly installs the native version of automake
instead of automake:armel.


garden-of-coloured-lights
-------------------------

Same as with freetalk.


mailsync
--------

Same as with freetalk.


worker
------

Build-Depends on sed:armel, which is essential. So same question as with
bomberclone.


Conclusion
==========

For this bugreport, the issues found with freetalk,
garden-of-coloured-lights, and mailsync seem to be most relevant.

libcatalyst-actionrole-acl-perl, obex-data-server, renattach and
trueprint seem to be situations in which the apt solver fails even
though there exists a solution. But that would be another bugreport.

The results of bomberclone and worker are debatable but I think the idea
of the multiarch spec is, that they should be treated like M-A: foreign
and that therefor a native essential packages satisfies foreign cross
build dependencies?


A bit off-topic
===============

Can I somehow force apt-get to satisfy the build dependencies for a
given source package and not fall back to another? It is really
bothersome to read:

Picking 'kmod' as source package instead of 'module-init-tools'

Why can I not use apt-get to satisfy the build dependencies for
module-init-tools? This effect occurs all over the place and means that
we cannot properly compare the output of apt-get and dose3 on a given
package list. It might mean that there are other packages out there that
dose3 and apt-get agree upon but only because apt-get actually decided
to chose a different source package instead. Because of this issue, the
information that there exist only 10 source packages on which apt-get
and dose3 disagree is very likely to be incorrect.


cheers, josch



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#683786; Package apt. (Sun, 05 Aug 2012 19:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Julian Andres Klode <jak@debian.org>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Sun, 05 Aug 2012 19:39:03 GMT) Full text and rfc822 format available.

Message #45 received at 683786@bugs.debian.org (full text, mbox):

From: Julian Andres Klode <jak@debian.org>
To: Johannes Schauer <j.schauer@email.de>, 683786@bugs.debian.org
Cc: David Kalnischkies <kalnischkies+debian@gmail.com>
Subject: Re: Bug#683786: apt-get cross build dependency resolution of arch:all, m-a:none packages
Date: Sun, 5 Aug 2012 21:37:02 +0200
On Sun, Aug 05, 2012 at 09:23:47PM +0200, Johannes Schauer wrote:
> obex-data-server
> ----------------
> 
> Build-Depends on libmagickwand-dev (>= 6.0.0) | libgtk2.0-dev.
> 
> >From those two choices, apt chooses to install libmagickwand-dev but
> fails to do so. Dose3 agrees that libmagickwand-dev is not installable,
> therefor it chooses to satisfy the build dependencies for
> obex-data-server using libgtk2.0-dev instead. Apt-get on the other hand
> doesnt try libgtk2.0-dev and therefor fails.

Packages in unstable must build using the first alternative, and the
buildds ignore any alternatives. So, if libmagickwand-dev is not
installable, the package has an RC bug as it FTBFS on the buildds
and must be fixed (is there one already???).

I don't have anything useful to say on the APT-side of that, though.

-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#683786; Package apt. (Sun, 05 Aug 2012 23:09:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to David Kalnischkies <kalnischkies+debian@gmail.com>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Sun, 05 Aug 2012 23:09:03 GMT) Full text and rfc822 format available.

Message #50 received at 683786@bugs.debian.org (full text, mbox):

From: David Kalnischkies <kalnischkies+debian@gmail.com>
To: Johannes Schauer <j.schauer@email.de>
Cc: 683786@bugs.debian.org
Subject: Re: Bug#683786: apt-get cross build dependency resolution of arch:all, m-a:none packages
Date: Mon, 6 Aug 2012 01:05:13 +0200
On Sun, Aug 5, 2012 at 9:23 PM, Johannes Schauer <j.schauer@email.de> wrote:
> Out of 18244 source package in Debian Sid, apt-get and dose3 now only
> disagree on 10 remaining packages

Wow. Thanks a lot for this analyze!


> (actually that number is only true
> assuming that apt bug#683917 would also be resolved).

I don't think we will fix that for wheezy as the cost/usage is to low
(we need at least one new string for this - and we have no sane exit
 code concept, so you wouldn't get a distinct one. If you need the
 functionality I can hack something together for testing, but it sounds
 like you already can detect that anyway).


> libcatalyst-actionrole-acl-perl
> obex-data-server
> trueprint

As Julian already said, these look like rc-bugs as only the first option
will be explored by sbuild (for consistency reasons).

APT could certainly do better in these situations, but that it doesn't
make it is okay for now as the fix is a lot of work for a greedy solver.
(We have a big FIXME for this in the build-dep code and I hope to get
 this code replaced by reusing our "normal" solver more, so this might
 get better in the future, but probably never really solved until we have
 a SAT (or its technical superior successor [invented by me] XYZ) solver…)

> qdox
> ----
>
> Was not able to make out what apt-get actually has a problem with.

I don't get it either, but APT seems to chuckle at getting all of
default-{jre{,-headless},jdk} installed which have a lot of provides, so
I guess it is also a "only the second alternative works" problem.
Also, some parts of the dependency tree do not seem to adapted to
multi-arch yet (e.g. libgif4 is M-A: none).


> renattach
> ---------
>
> Build-Depends on exim4 | mail-transport-agent.
>
>  Virtual packages like 'mail-transport-agent:armel' can't be removed

The error message is completely bogus, but harmless as it stems
from code reuse - and I will just disabled the printing of it.
(Enabled by the TryInstall change mentioned earlier)

> Dose3 on the other hand just satisfies the mail-transport-agent
> dependency using xmail and is done with it.

The reused code mentioned is used to detect if one package is the
sole provider - as mail-transport-agent is provided by many packages
it obviously doesn't find one (but many) and bails out prompting user
to choose one and install this first. It is intended behavior (or at least
it is that way for a long time now)

Slightly related, I seriously wonder what a package does that it build-deps
on a mail-transport-agent and procmail. I figured it might be tests, but
a testbuild without both works fine …


> Fail with dose3
> ===============
>
> Dose3 cannot satisfy the dependencies of the following source packages
> while apt-get can: bomberclone, freetalk, garden-of-coloured-lights,
> mailsync, worker.
>
>
> bomberclone
> -----------
>
> Build-depends on findutils:armel which clashes with the installed
> package findutils:amd64.
>
> Apt-get chooses to just remove findutils:amd64 and replaces it with
> findutils:armel. The multiarch cross spec doesnt cover this case so it
> is debatable whose behaviour is right.

APT prints a big warning and requires an insane confirmation string
to do this through, so I think both have the correct behavior here.
(assuming that dose3 isn't "talking" with the user on a regular base)


> Maybe the following section of the multiarch spec should apply to the
> cross case as well:
>
>> it is assumed that any undeclared dependencies on Essential packages
>> on the part of multiarch packages is satisfied by the binaries from
>> the native architecture
>
> Therefore, apt-get should not replace findutils:amd64 by findutils:armel
> and dose3 should see the findutils:armel dependency satisfied by
> findutils:amd64.
>
> But this has to be discussed in another place.

You lost me, I don't understand how this paragraph (speaking about
implicit dependencies on essential packages) could apply to explicit
dependencies.

This paragraph just tells us that we don't suddenly need to freak out
about implicit dependencies on essential packages as these are by
definition M-A:foreign. This, even if the difference is small, doesn't make
the package itself M-A:foreign. All it says is that a postinst script of
an armel package can copy files with 'cp' without worrying - the (most
likely) foreign cp will handle it just fine. Even through the package
coreutils isn't M-A:foreign yet.


> freetalk
> garden-of-coloured-lights
> mailsync
> --------
>
> Build-Depends on automake1.11 which is a virtual package provided by
> automake. Apt get wrongly installs the native version of automake
> instead of automake:armel.

The behavior of APT seems to be correct:
automake1.11 is provided by automake which is arch:all and M-A:foreign,
so any - preferable build-arch - satisfies the dependency. Right?


> A bit off-topic
> ===============
>
> Can I somehow force apt-get to satisfy the build dependencies for a
> given source package and not fall back to another? It is really
> bothersome to read:
>
> Picking 'kmod' as source package instead of 'module-init-tools'

Sounds like you want the ' --only-source' flag.
build-dep does a binary to source package mapping by default and only if no
binary package with that name exists uses the name to search for a source
package. The --only-source flag prevents the interpretation of packagenames
as binaries first (I presume the manpage should have a not about this for
 build-dep, not just the flag hidden in the long listing of all options).


Best regards

David Kalnischkies



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#683786; Package apt. (Mon, 06 Aug 2012 02:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Johannes Schauer <j.schauer@email.de>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Mon, 06 Aug 2012 02:51:03 GMT) Full text and rfc822 format available.

Message #55 received at 683786@bugs.debian.org (full text, mbox):

From: Johannes Schauer <j.schauer@email.de>
To: David Kalnischkies <kalnischkies+debian@gmail.com>
Cc: 683786@bugs.debian.org
Subject: Re: Bug#683786: apt-get cross build dependency resolution of arch:all, m-a:none packages
Date: Mon, 6 Aug 2012 04:47:35 +0200
Hi,

On Mon, Aug 06, 2012 at 01:05:13AM +0200, David Kalnischkies wrote:
> On Sun, Aug 5, 2012 at 9:23 PM, Johannes Schauer <j.schauer@email.de> wrote:
> > Out of 18244 source package in Debian Sid, apt-get and dose3 now only
> > disagree on 10 remaining packages
> Wow. Thanks a lot for this analyze!

I guess I'm just as interested in making my tool work as you are in
yours ;)

> > (actually that number is only true assuming that apt bug#683917
> > would also be resolved).
> 
> I don't think we will fix that for wheezy as the cost/usage is to low
> (we need at least one new string for this - and we have no sane exit
> code concept, so you wouldn't get a distinct one. If you need the
> functionality I can hack something together for testing, but it sounds
> like you already can detect that anyway).

Yes, it's not of importance for me anymore. I just first generate the
list of source packages that can actually be compiled for an
architecture with my tools and feed only those to apt.

> We have a big FIXME for this in the build-dep code and I hope to get
> this code replaced by reusing our "normal" solver more, so this might
> get better in the future, but probably never really solved until we
> have a SAT (or its technical superior successor [invented by me] XYZ)
> solver…

You are writing a solver?

> Slightly related, I seriously wonder what a package does that it
> build-deps on a mail-transport-agent and procmail. I figured it might
> be tests, but a testbuild without both works fine …

Those useless dependencies give me multiple headaches - my GSoC project
is bootstrapping Debian and useless dependencies like this just create
so many new cyclic dependency situations for nothing...

> You lost me, I don't understand how this paragraph (speaking about
> implicit dependencies on essential packages) could apply to explicit
> dependencies.

It is not - but nothing else there talks about essential packages.

> This paragraph just tells us that we don't suddenly need to freak out
> about implicit dependencies on essential packages as these are by
> definition M-A:foreign. This, even if the difference is small, doesn't
> make the package itself M-A:foreign. All it says is that a postinst
> script of an armel package can copy files with 'cp' without worrying -
> the (most likely) foreign cp will handle it just fine. Even through
> the package coreutils isn't M-A:foreign yet.

Good, then I will also let dose3 keep on failing for those two packages.

> The behavior of APT seems to be correct:
> automake1.11 is provided by automake which is arch:all and M-A:foreign,
> so any - preferable build-arch - satisfies the dependency. Right?

You are right. I must've developed too much confidence in my tools and
thereby have overlooked that automake is indeed M-A:foreign.

The error is in dose3 here, which does not (yet, but will tomorrow)
apply multiarch properties to the virtual packages it provides.

> Sounds like you want the ' --only-source' flag.  build-dep does a
> binary to source package mapping by default and only if no binary
> package with that name exists uses the name to search for a source
> package. The --only-source flag prevents the interpretation of
> packagenames as binaries first (I presume the manpage should have a
> not about this for build-dep, not just the flag hidden in the long
> listing of all options).

Yeah somehow I failed to find that option. I'm using it now and started
just another run across all source packages. :)

Thanks again for your quick reply! :D

cheers, josch



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#683786; Package apt. (Mon, 06 Aug 2012 11:48:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Johannes Schauer <j.schauer@email.de>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Mon, 06 Aug 2012 11:48:03 GMT) Full text and rfc822 format available.

Message #60 received at 683786@bugs.debian.org (full text, mbox):

From: Johannes Schauer <j.schauer@email.de>
To: David Kalnischkies <kalnischkies+debian@gmail.com>
Cc: 683786@bugs.debian.org
Subject: Re: Bug#683786: apt-get cross build dependency resolution of arch:all, m-a:none packages
Date: Mon, 6 Aug 2012 13:44:45 +0200
Hi,

On Mon, Aug 06, 2012 at 01:05:13AM +0200, David Kalnischkies wrote:
> On Sun, Aug 5, 2012 at 9:23 PM, Johannes Schauer <j.schauer@email.de> wrote:
> > Out of 18244 source package in Debian Sid, apt-get and dose3 now
> > only disagree on 10 remaining packages

I now re-ran the comparison using "--only-source".

There are no more differences between dose3 and apt-get in terms of
satisfying cross build dependencies than those 10 that I pointed out in
my last mail.

Hope the latest version of your patch makes it into apt and the archive
soon :)

Thanks for your help and quick fixing of the issue!

cheers, josch



Information forwarded to debian-bugs-dist@lists.debian.org, APT Development Team <deity@lists.debian.org>:
Bug#683786; Package apt. (Mon, 06 Aug 2012 15:48:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to David Kalnischkies <kalnischkies+debian@gmail.com>:
Extra info received and forwarded to list. Copy sent to APT Development Team <deity@lists.debian.org>. (Mon, 06 Aug 2012 15:48:03 GMT) Full text and rfc822 format available.

Message #65 received at 683786@bugs.debian.org (full text, mbox):

From: David Kalnischkies <kalnischkies+debian@gmail.com>
To: Johannes Schauer <j.schauer@email.de>
Cc: 683786@bugs.debian.org
Subject: Re: Bug#683786: apt-get cross build dependency resolution of arch:all, m-a:none packages
Date: Mon, 6 Aug 2012 17:45:20 +0200
On Mon, Aug 6, 2012 at 1:44 PM, Johannes Schauer <j.schauer@email.de> wrote:
> On Mon, Aug 06, 2012 at 01:05:13AM +0200, David Kalnischkies wrote:
>> On Sun, Aug 5, 2012 at 9:23 PM, Johannes Schauer <j.schauer@email.de> wrote:
>> > Out of 18244 source package in Debian Sid, apt-get and dose3 now
>> > only disagree on 10 remaining packages
>
> I now re-ran the comparison using "--only-source".
>
> There are no more differences between dose3 and apt-get in terms of
> satisfying cross build dependencies than those 10 that I pointed out in
> my last mail.

Wow! So the amount of programs (possibly) completely wrong about how
cross-build-dependencies should be evaluated doubled! ;)

I hope I will find some time myself to play with dose3 stuff soon,
its on the list for some time. I will wait for an official build and
your next GSoC report through.


> Hope the latest version of your patch makes it into apt and the archive
> soon :)

I see no problem with that given that it is well tested thanks to your work!

Were is a bunch of other stuff on the plate through so it might take
a few days until it hits unstable (and later testing).


Best regards

David Kalnischkies



Reply sent to Michael Vogt <mvo@debian.org>:
You have taken responsibility. (Mon, 06 Aug 2012 16:03:21 GMT) Full text and rfc822 format available.

Notification sent to Johannes Schauer <j.schauer@email.de>:
Bug acknowledged by developer. (Mon, 06 Aug 2012 16:03:21 GMT) Full text and rfc822 format available.

Message #70 received at 683786-close@bugs.debian.org (full text, mbox):

From: Michael Vogt <mvo@debian.org>
To: 683786-close@bugs.debian.org
Subject: Bug#683786: fixed in apt 0.9.7.4
Date: Mon, 06 Aug 2012 16:02:15 +0000
Source: apt
Source-Version: 0.9.7.4

We believe that the bug you reported is fixed in the latest version of
apt, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 683786@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Michael Vogt <mvo@debian.org> (supplier of updated apt package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Mon, 06 Aug 2012 15:55:04 +0200
Source: apt
Binary: apt libapt-pkg4.12 libapt-inst1.5 apt-doc libapt-pkg-dev libapt-pkg-doc apt-utils apt-transport-https
Architecture: source all amd64
Version: 0.9.7.4
Distribution: unstable
Urgency: low
Maintainer: APT Development Team <deity@lists.debian.org>
Changed-By: Michael Vogt <mvo@debian.org>
Description: 
 apt        - commandline package manager
 apt-doc    - documentation for APT
 apt-transport-https - https download transport for APT
 apt-utils  - package managment related utility programs
 libapt-inst1.5 - deb package format runtime library
 libapt-pkg-dev - development files for APT's libapt-pkg and libapt-inst
 libapt-pkg-doc - documentation for APT development
 libapt-pkg4.12 - package managment runtime library
Closes: 676302 683109 683354 683410 683786
Changes: 
 apt (0.9.7.4) unstable; urgency=low
 .
   [ Manpages translation updates ]
   * Polish (Robert Luberda) (Closes: #683109)
 .
   [ Program translation updates ]
   * Polish (Michał Kułach)
 .
   [ Pino Toscano ]
   * apt-pkg/contrib/mmap.cc:
     - 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)
 .
   [ David Kalnischkies ]
   * 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
   * 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
   * doc/apt-verbatim.ent:
     - denote 'wheezy' as stable codename and 'jessie' as testing codename
       in the documentation in preparation for release
   * 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 automically. (Closes: #683410)
   * 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)
Checksums-Sha1: 
 bba2fe56bd1d64ddcd943165424f96f2689be40b 1689 apt_0.9.7.4.dsc
 f813e7db6d5f39991e5bc6fc9e479f33b6d970e3 3389724 apt_0.9.7.4.tar.gz
 ede60bb8b310d010c17702284304f71a7549cdbf 260128 apt-doc_0.9.7.4_all.deb
 cbb7d0b51331512cc9dc655ba0dc1a9cc15e6b27 958974 libapt-pkg-doc_0.9.7.4_all.deb
 6f1db7f1a25faf602e4f03cd16d5b1eed1971a36 880586 libapt-pkg4.12_0.9.7.4_amd64.deb
 f4c0f1d461347529889bf571cc8209e70256d3c4 163764 libapt-inst1.5_0.9.7.4_amd64.deb
 38e2ff456f1c643736a4698a4c1310d72de42417 1153106 apt_0.9.7.4_amd64.deb
 92955a30b2cd7b65b9ac744d2020c9443c25e625 184658 libapt-pkg-dev_0.9.7.4_amd64.deb
 9360c43cc8ed0370f0f1190dd63b7e6b1f030a5d 373558 apt-utils_0.9.7.4_amd64.deb
 f9d335001d0ec1f4320632c5034779311a935697 106346 apt-transport-https_0.9.7.4_amd64.deb
Checksums-Sha256: 
 e495e1d6f363999c16598a1fd39c21e832bdec5ea2677e5d4dbccff5f72ec492 1689 apt_0.9.7.4.dsc
 31745b8567287baa5443e970044a54693d2a1488f6b70d29c8357c844d2615a9 3389724 apt_0.9.7.4.tar.gz
 55a2bd6e546066e7b8148dc4acff06fe3ba072fe6c009b79d2d63ab3b7d6af29 260128 apt-doc_0.9.7.4_all.deb
 dfe286763332f965cca710f50381c46382889ca5a0b2aad971ab07df3cf1118d 958974 libapt-pkg-doc_0.9.7.4_all.deb
 9550210e6adac0f12619e384fab8ecc298943b5f6b0fe539af817e1f1d145ba9 880586 libapt-pkg4.12_0.9.7.4_amd64.deb
 c74027e605c7225635aaba89d7ebd2e092a20c5326cc48416084e6f607b25723 163764 libapt-inst1.5_0.9.7.4_amd64.deb
 bbaee2cf937525eddf5de12ccf8cd28cca0102f9cd9a9add23b70a4a2afbc6ef 1153106 apt_0.9.7.4_amd64.deb
 e6335d09e6924cacd3e222941730848ea73424c3d23cf2b746e97da8754e6359 184658 libapt-pkg-dev_0.9.7.4_amd64.deb
 7f23b6e5393f6c0644a6c1e8a645dac01d9a3453d0d2c6060aa6b2dc75553bde 373558 apt-utils_0.9.7.4_amd64.deb
 229f1a688a49b36205498290fb7a2cd0e921e0564e9e5201bdf63109a53eb9fe 106346 apt-transport-https_0.9.7.4_amd64.deb
Files: 
 19e3fcbdb26756087f84960e9d5b1778 1689 admin important apt_0.9.7.4.dsc
 a433cbc6b6d124863ef61c7963ce4aca 3389724 admin important apt_0.9.7.4.tar.gz
 53374023402f34191a5fcfcaf5090d42 260128 doc optional apt-doc_0.9.7.4_all.deb
 181a99da9aa5583cff07b4259041f35f 958974 doc optional libapt-pkg-doc_0.9.7.4_all.deb
 41d6193d0c7e6873eb976ea6861d86e7 880586 libs important libapt-pkg4.12_0.9.7.4_amd64.deb
 0f100fe68bd4b0f615a01c7833fb6ce2 163764 libs important libapt-inst1.5_0.9.7.4_amd64.deb
 896ba34fded7a1ce6bdb9f9ed081036d 1153106 admin important apt_0.9.7.4_amd64.deb
 8cf55b2bcdf6ec622b935c66979fb694 184658 libdevel optional libapt-pkg-dev_0.9.7.4_amd64.deb
 161a81f1e7b7233b80b2552ce4a9c68c 373558 admin important apt-utils_0.9.7.4_amd64.deb
 5df4fe7b338ae7703ec0b17cb3768217 106346 admin optional apt-transport-https_0.9.7.4_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlAf51UACgkQliSD4VZixzTgRQCeJmHyVzUmvCzCXUp1OWHQzDx+
kIYAnReo/UQTAHkz09mRteThcjtjguqb
=TTeF
-----END PGP SIGNATURE-----




Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Thu, 06 Sep 2012 07:28:30 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Mon Apr 21 03:17:40 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.