Re: Bug#839145: dpkg-checkbuilddeps: Incorrect "Unmet build dependencies" error for Multi-Arch: foreign :native-qualified dependency
On Sun, 2016-10-16 at 15:53 +0200, Guillem Jover wrote: > Hi! > > On Sat, 2016-10-01 at 21:07:30 +0100, Ben Hutchings wrote: [...] > > You seem to be saying that dpkg won't allow an M-A foreign package to > > satisfy a :native dependency, even if the package is native. Which > > would mean we can't both support cross-building with openssl 1.0, and > > building with openssl 1.1, from the same source package. > > > I think in this particular case, the correct solution is to also fix > openssl 1.0 in unstable with the correct annotations so that there's > no divergence between the suites. Is there any reason that would be > problematic? [...] That doesn't seem problematic to me. It would also need to be updated in jessie-backports. But rather than blocking on that, I will change linux's build-depdendency to: openssl (>= 1.1.0-1~) | openssl:native With that, dpkg-checkbuilddeps seems satisfied with either openssl 1.0.2j-1 or 1.1.0b-2 installed, and with or without the -aarmhf option. Ben. -- Ben Hutchings The world is coming to an end. Please log off signature.asc Description: This is a digitally signed message part
Re: Bug#839145: dpkg-checkbuilddeps: Incorrect "Unmet build dependencies" error for Multi-Arch: foreign :native-qualified dependency
Hi! On Sat, 2016-10-01 at 21:07:30 +0100, Ben Hutchings wrote: > On Fri, 2016-09-30 at 02:08 +0200, Guillem Jover wrote: > > On Thu, 2016-09-29 at 13:39:30 +0100, James Clarke wrote: > > > Package: libdpkg-perl > > > Version: 1.18.10 > > > Control: affects -1 src:linux > > > X-Debbugs-Cc: debian-sp...@lists.debian.org > > > User: debian-sp...@lists.debian.org > > > Usertags: sparc64 > > > Currently, src:linux FTBFS in experimental on sparc64[1], with the error: > > > > > > dpkg-checkbuilddeps: error: Unmet build dependencies: openssl:native > > > > > > However, as you can see from the build log, openssl_1.1.0b-1(_sparc64) is > > > installed. This is the version from experimental, rather than the version > > > from > > > unstable which is used on all the other buildds, since sparc64 is unable > > > to use > > > the aspcud resolver[2], and so the apt resolver ends up pulling in more > > > experimental packages than actually needed, but if and when openssl 1.1.0 > > > hits > > > unstable, this will affect *all* architectures. This is because > > > Multi-Arch: foreign was added to openssl 1.1.0 in experimental (see > > > #827028), > > > and it seems _find_package in /usr/share/perl5/Dpkg/Deps.pm:1472 requires > > > :native dependencies to not be Multi-Arch: foreign. > > > > Yes (as mentioned on IRC), this is as intended and documented in > > deb-src-control(5). The rationale is that a :native build dependency on > > M-A:foreign package is non-sensical, one of the markings is wrong > > because if the interface is arch-indep then requesting the native > > should not be required. > [...] > > I know it's nonsensical, but this was done as a workaround for #827028. This was just what I deduced could be the implicit rationale for that behavior. > You seem to be saying that dpkg won't allow an M-A foreign package to > satisfy a :native dependency, even if the package is native. Which > would mean we can't both support cross-building with openssl 1.0, and > building with openssl 1.1, from the same source package. I think in this particular case, the correct solution is to also fix openssl 1.0 in unstable with the correct annotations so that there's no divergence between the suites. Is there any reason that would be problematic? > Please can you allow this 'nonsensical' case so that we are not forced > into a choice between two possible build regressions? I've contacted the original authors of the MultiArchCorss spec, and they confirmed the reason for the current behavior. I've also been talking with Helmut Grohne and Johannes Schauer about this, and we were pondering that it might indeed make sense to relax this restriction, but I'd probably like to discuss it with a wider audience before changing it. Thanks, Guillem
Processed: Re: Bug#839145: dpkg-checkbuilddeps: Incorrect "Unmet build dependencies" error for Multi-Arch: foreign :native-qualified dependency
Processing control commands: > tag -1 moreinfo Bug #839145 [src:linux] dpkg-checkbuilddeps: Incorrect "Unmet build dependencies" error for Multi-Arch: foreign :native-qualified dependency Added tag(s) moreinfo. -- 839145: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839145 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: Bug#839145: dpkg-checkbuilddeps: Incorrect "Unmet build dependencies" error for Multi-Arch: foreign :native-qualified dependency
Control: tag -1 moreinfo On Fri, 2016-09-30 at 02:08 +0200, Guillem Jover wrote: > Control: reassign -1 src:linux > > On Thu, 2016-09-29 at 13:39:30 +0100, James Clarke wrote: > > > > Package: libdpkg-perl > > Version: 1.18.10 > > Control: affects -1 src:linux > > X-Debbugs-Cc: debian-sp...@lists.debian.org > > User: debian-sp...@lists.debian.org > > Usertags: sparc64 > > > > > Currently, src:linux FTBFS in experimental on sparc64[1], with the error: > > > > dpkg-checkbuilddeps: error: Unmet build dependencies: openssl:native > > > > However, as you can see from the build log, openssl_1.1.0b-1(_sparc64) is > > installed. This is the version from experimental, rather than the version > > from > > unstable which is used on all the other buildds, since sparc64 is unable to > > use > > the aspcud resolver[2], and so the apt resolver ends up pulling in more > > experimental packages than actually needed, but if and when openssl 1.1.0 > > hits > > unstable, this will affect *all* architectures. This is because > > Multi-Arch: foreign was added to openssl 1.1.0 in experimental (see > > #827028), > > and it seems _find_package in /usr/share/perl5/Dpkg/Deps.pm:1472 requires > > :native dependencies to not be Multi-Arch: foreign. > > Yes (as mentioned on IRC), this is as intended and documented in > deb-src-control(5). The rationale is that a :native build dependency on > M-A:foreign package is non-sensical, one of the markings is wrong > because if the interface is arch-indep then requesting the native > should not be required. [...] I know it's nonsensical, but this was done as a workaround for #827028. You seem to be saying that dpkg won't allow an M-A foreign package to satisfy a :native dependency, even if the package is native. Which would mean we can't both support cross-building with openssl 1.0, and building with openssl 1.1, from the same source package. Please can you allow this 'nonsensical' case so that we are not forced into a choice between two possible build regressions? Ben. -- Ben Hutchings Klipstein's 4th Law of Prototyping and Production: A fail-safe circuit will destroy others. signature.asc Description: This is a digitally signed message part
Processed: Re: Bug#839145: dpkg-checkbuilddeps: Incorrect "Unmet build dependencies" error for Multi-Arch: foreign :native-qualified dependency
Processing control commands: > reassign -1 src:linux Bug #839145 [libdpkg-perl] dpkg-checkbuilddeps: Incorrect "Unmet build dependencies" error for Multi-Arch: foreign :native-qualified dependency Bug reassigned from package 'libdpkg-perl' to 'src:linux'. No longer marked as found in versions dpkg/1.18.10. Ignoring request to alter fixed versions of bug #839145 to the same values previously set -- 839145: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839145 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: Bug#839145: dpkg-checkbuilddeps: Incorrect "Unmet build dependencies" error for Multi-Arch: foreign :native-qualified dependency
Control: reassign -1 src:linux On Thu, 2016-09-29 at 13:39:30 +0100, James Clarke wrote: > Package: libdpkg-perl > Version: 1.18.10 > Control: affects -1 src:linux > X-Debbugs-Cc: debian-sp...@lists.debian.org > User: debian-sp...@lists.debian.org > Usertags: sparc64 > Currently, src:linux FTBFS in experimental on sparc64[1], with the error: > > dpkg-checkbuilddeps: error: Unmet build dependencies: openssl:native > > However, as you can see from the build log, openssl_1.1.0b-1(_sparc64) is > installed. This is the version from experimental, rather than the version from > unstable which is used on all the other buildds, since sparc64 is unable to > use > the aspcud resolver[2], and so the apt resolver ends up pulling in more > experimental packages than actually needed, but if and when openssl 1.1.0 hits > unstable, this will affect *all* architectures. This is because > Multi-Arch: foreign was added to openssl 1.1.0 in experimental (see #827028), > and it seems _find_package in /usr/share/perl5/Dpkg/Deps.pm:1472 requires > :native dependencies to not be Multi-Arch: foreign. Yes (as mentioned on IRC), this is as intended and documented in deb-src-control(5). The rationale is that a :native build dependency on M-A:foreign package is non-sensical, one of the markings is wrong because if the interface is arch-indep then requesting the native should not be required. > As it happens, the :native arch qualification (according to the > comments) seems to be a workaround for since-closed bugs in > libdpkg-perl, but as far as I can tell, they should have been satisfied > in this case. So the assumtion here is that this is a problem in linux. Thus reassigning. Thanks, Guillem
