Bug#958414: Latest equivs version 2.3.0 breaks mk-build-deps
Hi Guillem, Guillem Jover wrote: > > A maybe a bit safer variant would be to call dpkg-checkbuilddeps > > beforehand and filter out build-essential if it appears. That way > > around it should hurt way less to hardcode the package name. > > You can simply use --ignore-builtin-builddeps. :) Argh! It could have been so simple! Thanks! Unfortunately I just uploaded a new equivs version less than a day ago. Will convert this from -d to this anyway with the next upload. Will though probably wait until the current version has been migrated to testing due to the RC bug fix. (Although this is the better fix for that issue.) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#958414: Latest equivs version 2.3.0 breaks mk-build-deps
Hi!
On Tue, 2020-05-26 at 17:59:33 +0200, Axel Beckert wrote:
> Johannes Schauer wrote:
> > And I got the same error as Otto ("Unmet build dependencies:
> > build-essential:native")
> One idea was to add some logic to automatically decide if we can use
> dpkg-buildpackage or not and if not, fall back to the old method by
> calling debian/rules directly which would partially reopen #880165.
>
> It seems as if build-essential gets automatically added to the build
> dependencies by Dpkg::Vendor::Debian. So this might even be different
> in other derivative distributions, hence we should neither hardcode it
> as dependency nor should we test of it being installed or not.
>
> But since equivs nearly never compiles stuff but is for metapackages,
> the simple solution is probably to run dpkg-buildpackage always with
> --no-check-builddeps.
[…]
> A maybe a bit safer variant would be to call dpkg-checkbuilddeps
> beforehand and filter out build-essential if it appears. That way
> around it should hurt way less to hardcode the package name.
You can simply use --ignore-builtin-builddeps. :)
Thanks,
Guillem
Bug#958414: Latest equivs version 2.3.0 breaks mk-build-deps
Hi josch,
Johannes Schauer wrote:
> > If it's similar as with mk-ci-build-deps above, this is likely a bug in
> > mk-build-deps then, just triggered by equivs.
>
> Again, I don't want to be confrontational here.
Ok. Already forgotten. :-)
> I don't understand as much
> about equivs as you do. But what I tested is completely independent from
> mk-build-deps. What I tried was running:
>
> equivs-build /usr/share/doc/equivs/examples/webserver.ctl
>
> And I got the same error as Otto ("Unmet build dependencies:
> build-essential:native")
Sorry, it took me quite a while to realise that I couldn't reproduce
the problem because even in the "clean" pbuilder chroot (which is
meant for building packages) build-essential is pre-installed and
hence the build succeeds. I of course also have it installed
everywhere else where I work on equivs, too.
Then again, a hard dependency on build-essential which pulls in gcc
and g++ is definitely way too much for equivs which is aimed to be
quick and lightweight.
One idea was to add some logic to automatically decide if we can use
dpkg-buildpackage or not and if not, fall back to the old method by
calling debian/rules directly which would partially reopen #880165.
It seems as if build-essential gets automatically added to the build
dependencies by Dpkg::Vendor::Debian. So this might even be different
in other derivative distributions, hence we should neither hardcode it
as dependency nor should we test of it being installed or not.
But since equivs nearly never compiles stuff but is for metapackages,
the simple solution is probably to run dpkg-buildpackage always with
--no-check-builddeps.
Will first implement this.
A maybe a bit safer variant would be to call dpkg-checkbuilddeps
beforehand and filter out build-essential if it appears. That way
around it should hurt way less to hardcode the package name.
Will likely implement this afterwards.
Will then also merge your autopkgtest checks as they should show as
well that (or if ;-) this variant works.
P.S.: The workaround for now is to install build-essential even if not
used in the end.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#958414: Latest equivs version 2.3.0 breaks mk-build-deps
Quoting Otto Kekäläinen (2020-05-26 15:56:04) > Yes, installing build-essential manually has been the work-around I've > been using. So that is now the permanent solution? No, I think that now that equivs always uses dpkg-buildpackage instead of manually invoking debian/rules it *must* depend on build-essential because unless you tell dpkg-buildpackage to skip checking build dependencies, the build-essential packages is required due to its call to dpkg-checkbuilddeps. So as a workaround you could either: - install packages with recommends enabled (this will install build-essential because dpkg-dev recommends it) - or install build-essential manually But the long-term solution is probably to add build-essential to the Depends of equivs. signature.asc Description: signature
Bug#958414: Latest equivs version 2.3.0 breaks mk-build-deps
Yes, installing build-essential manually has been the work-around I've been using. So that is now the permanent solution?
Bug#958414: Latest equivs version 2.3.0 breaks mk-build-deps
Hi Otto, On Tue, 21 Apr 2020 21:54:57 +0300 =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?= wrote: > I noticed my builds started failing today with error message: > > Step 4/7 : RUN DEBIAN_FRONTEND=noninteractive mk-build-deps -r -i > control -t 'apt-get -y -o Debug::pkgProblemResolver=yes > --no-install-recommends' > ---> Running in 912092c7ebbd > dpkg-buildpackage: info: source package mariadb-10.5-build-deps > dpkg-buildpackage: info: source version 1.0 > dpkg-buildpackage: info: source distribution unstable > dpkg-buildpackage: info: source changed by root > dpkg-source --before-build . > dpkg-buildpackage: info: host architecture amd64 > dpkg-checkbuilddeps: error: Unmet build dependencies: build-essential:native > dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting > dpkg-buildpackage: warning: (Use -d flag to override.) > Error in the build process: exit status 3 > dpkg: error: cannot access archive > 'mariadb-10.5-build-deps_1.0_amd64.deb': No such file or directory > mk-build-deps: dpkg --unpack failed > The command '/bin/sh -c DEBIAN_FRONTEND=noninteractive mk-build-deps > -r -i control -t 'apt-get -y -o Debug::pkgProblemResolver=yes > --no-install-recommends'' returned a non-zero code: 2 > > I am pretty sure this is related to the recent equivs 2.3.0 release, > but I have not figured out the details yet. > > > Run the attached Dockerfile to reproduce. could you try adding the package build-essential to the "apt-get install" command in your Dockerfile and see if the problem persists? I think the trivial reason for this issue is, that equivs now always uses dpkg-buildpackage (see #880165 or commit c1f8ba) but it didn't add a dependency on build-essential. The build-essential package is only a Recommends of dpkg-dev and thus it is not guaranteed to be installed just by depending on dpkg-dev. Thanks! cheers, josch signature.asc Description: signature
Bug#958414: Latest equivs version 2.3.0 breaks mk-build-deps
Hi Axel,
Quoting Axel Beckert (2020-05-07 15:45:12)
> > bisection finished successfully
> > last good timestamp: 2020-04-19 06:52:31.476563+02:00
> > first bad timestamp: 2020-04-19 10:35:09.156250+02:00
> > only one package differs: equivs is the culprit
> Yeah, but we know that already. I still haven't understood what exactly
> causes this issue.
sorry, me writing this was not supposed to come across as "I think that you are
wrong, so here is further evidence that I'm right". Instead, all I knew was
what was written by Otto and (same as myself) Otto wasn't sure whether this was
a bug in equivs or something else. So what I wanted to say was "this problem
indeed only started happening once the new equivs version got uploaded".
> If it's similar as with mk-ci-build-deps above, this is likely a bug in
> mk-build-deps then, just triggered by equivs.
Again, I don't want to be confrontational here. I don't understand as much
about equivs as you do. But what I tested is completely independent from
mk-build-deps. What I tried was running:
equivs-build /usr/share/doc/equivs/examples/webserver.ctl
And I got the same error as Otto ("Unmet build dependencies:
build-essential:native") -- even when I tried with all the other control files
in the examples directory. So if the bug is indeed not in equivs, then there
must be a bug in the control files?
Sorry if I came across as confrontational -- that was not my intention. Please
ignore this mail in case I still didn't manage to make sense.
Thanks!
cheers, josch
signature.asc
Description: signature
Bug#958414: Latest equivs version 2.3.0 breaks mk-build-deps
Hi Josch, thanks for bringing this to my attention. It seems as if I have overseen Otto's bug report wen it came in two weeks ago. (Sorry, Otto.) Johannes Schauer wrote: > Otto Kekäläinen wrote: > > I am pretty sure this is related to the recent equivs 2.3.0 release, > > but I have not figured out the details yet. Some things have changed slightly in equivs and might need adaptions in scripts using them where they make assumptions never guaranteed and now no more true, like that only a .deb file is produced. E.g. now it also produces .changes and .buildinfo files, see e.g. https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/154 > bisection finished successfully > last good timestamp: 2020-04-19 06:52:31.476563+02:00 > first bad timestamp: 2020-04-19 10:35:09.156250+02:00 > only one package differs: equivs is the culprit Yeah, but we know that already. I still haven't understood what exactly causes this issue. If it's similar as with mk-ci-build-deps above, this is likely a bug in mk-build-deps then, just triggered by equivs. > Notice that the test-command executes equivs-build with one of the provided > examples (webserver.ctl), so the problem is not mk-build-deps specific. Ok, will have a look at this closer. > I wrote an autopkgtest which also demonstrates the problem: > > https://salsa.debian.org/perl-team/modules/packages/equivs/-/merge_requests/5 Will likely merge it once I've understood the cause of issue. Thanks for the test! Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#958414: Latest equivs version 2.3.0 breaks mk-build-deps
Control: severity -1 grave On Tue, 21 Apr 2020 21:54:57 +0300 =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?= wrote: > I noticed my builds started failing today with error message: > > Step 4/7 : RUN DEBIAN_FRONTEND=noninteractive mk-build-deps -r -i > control -t 'apt-get -y -o Debug::pkgProblemResolver=yes > --no-install-recommends' > ---> Running in 912092c7ebbd > dpkg-buildpackage: info: source package mariadb-10.5-build-deps > dpkg-buildpackage: info: source version 1.0 > dpkg-buildpackage: info: source distribution unstable > dpkg-buildpackage: info: source changed by root > dpkg-source --before-build . > dpkg-buildpackage: info: host architecture amd64 > dpkg-checkbuilddeps: error: Unmet build dependencies: build-essential:native > dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting > dpkg-buildpackage: warning: (Use -d flag to override.) > Error in the build process: exit status 3 > dpkg: error: cannot access archive > 'mariadb-10.5-build-deps_1.0_amd64.deb': No such file or directory > mk-build-deps: dpkg --unpack failed > The command '/bin/sh -c DEBIAN_FRONTEND=noninteractive mk-build-deps > -r -i control -t 'apt-get -y -o Debug::pkgProblemResolver=yes > --no-install-recommends'' returned a non-zero code: 2 > > I am pretty sure this is related to the recent equivs 2.3.0 release, > but I have not figured out the details yet. It is quite certain that the problem was introduced with the equivs 2.3.0 release. If you run the "debbisect" script from this merge request https://salsa.debian.org/debian/devscripts/-/merge_requests/177#note_148500 then you will get: $ ./scripts/debbisect --depends=equivs --cache=./cache 2020-04-18 2020-04-20 'chroot "$1" equivs-build /usr/share/doc/equivs/examples/webserver.ctl' [...] bisection finished successfully last good timestamp: 2020-04-19 06:52:31.476563+02:00 first bad timestamp: 2020-04-19 10:35:09.156250+02:00 only one package differs: equivs is the culprit Notice that the test-command executes equivs-build with one of the provided examples (webserver.ctl), so the problem is not mk-build-deps specific. I wrote an autopkgtest which also demonstrates the problem: https://salsa.debian.org/perl-team/modules/packages/equivs/-/merge_requests/5 Since all examples fail with the message "Unmet build dependencies: build-essential:native" I'm raising the severity to grave. I'm not able to find a way to craft a control file that is still working with equivs. Thanks! cheers, josch signature.asc Description: signature
Bug#958414: Latest equivs version 2.3.0 breaks mk-build-deps
Package: equivs Version: 2.3.0 I noticed my builds started failing today with error message: Step 4/7 : RUN DEBIAN_FRONTEND=noninteractive mk-build-deps -r -i control -t 'apt-get -y -o Debug::pkgProblemResolver=yes --no-install-recommends' ---> Running in 912092c7ebbd dpkg-buildpackage: info: source package mariadb-10.5-build-deps dpkg-buildpackage: info: source version 1.0 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by root dpkg-source --before-build . dpkg-buildpackage: info: host architecture amd64 dpkg-checkbuilddeps: error: Unmet build dependencies: build-essential:native dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting dpkg-buildpackage: warning: (Use -d flag to override.) Error in the build process: exit status 3 dpkg: error: cannot access archive 'mariadb-10.5-build-deps_1.0_amd64.deb': No such file or directory mk-build-deps: dpkg --unpack failed The command '/bin/sh -c DEBIAN_FRONTEND=noninteractive mk-build-deps -r -i control -t 'apt-get -y -o Debug::pkgProblemResolver=yes --no-install-recommends'' returned a non-zero code: 2 I am pretty sure this is related to the recent equivs 2.3.0 release, but I have not figured out the details yet. Run the attached Dockerfile to reproduce. - Otto Dockerfile.mariadb-10.5-debian-sid-build-env Description: Binary data
