Hi, Quoting Antoine Beaupré (2022-05-26 16:19:53) > On 2022-05-26 16:03:04, Christian Kastner wrote: > > On 2022-05-25 17:40, Antoine Beaupre wrote: > >> Setting up dose-distcheck (7.0.0-1+b1) ... > >> Setting up sbuild-build-depends-dose3-dummy (0.invalid.0) ... > >> (I)Doseparse: Parsing and normalizing... > >> (I)Dose_deb: Parsing Packages file -... > >> > >> ... and then it's just *stuck* there forever. In fact, even getting > >> rid of that thing is hard: just one good old control-c doesn't cut > >> it. You need to ^C the *heck* out of it and it eventually succeeds. > >> > >> I would expect this to fail early. In fact, there *is* an error in apt > >> earlier, but it seems the error is ignored as it just carries on from > >> there: > >> > >> The following packages have unmet dependencies: > >> sbuild-build-depends-main-dummy : Depends: python (>= 2.7) but it is not > >> installable > >> E: Unable to correct problems, you have held broken packages. > >> apt-get failed. > >> E: Package installation failed > > > > I've seen this super-hard-to-kill hang with dose encountering > > uninstallable packages before (although it seems that I didn't file a > > bug about this). > > > > The simple solution that I found was to use apt as the build dependency > > resolver. To this end, sbuild-qemu passes > > > > --bd-uninstallable-explainer apt > > > > to sbuild. And on my host, gbp cloning userdir-ldap and running > > > > $ sbuild-qemu *.dsc > > > > terminates just fine with an error message. > > > > What's odd is that this sbuild option seems to get lost on your end. Are > > you perhaps overriding this option somehow? > > > > Otherwise, I would suspect an option parsing issue similar to the > > --overlay-dir issue that we have been discussing privately. > > > > Will look into this, but if you have any info on a possible override of > > --bd-uninstallable-explainer to share, please do. > > I don't believe I do have an override like this. Attached is my (messy) > .sbuildrc.
your sbuildrc contains some stuff that I find weird but nothing that should
have the effect you are seeing.
Since I'm also maintaining dose3, I'm very interested in reproducing the
problem. Unfortunately, I cannot build the package you are building as it uses
debhelper compat 5 which is not only deprecated since 2016 but also completely
removed from current debhelper. I fixed this locally and am unable to reproduce
your problem:
Setting up sbuild-build-depends-dose3-dummy (0.invalid.0) ...
(I)Doseparse: Parsing and normalizing...
(I)Dose_deb: Parsing Packages file -...
(I)Dose_common: total packages 66626
(I)Dose_applications: Cudf Universe: 66626 packages
(I)Dose_applications: --checkonly specified, consider all packages as
background packages
(I)Dose_applications: Solving...
output-version: 1.2
native-architecture: amd64
report:
-
package: sbuild-build-depends-main-dummy
version: 0.invalid.0
architecture: amd64
status: broken
reasons:
-
missing:
pkg:
package: sbuild-build-depends-main-dummy
version: 0.invalid.0
architecture: amd64
unsat-dependency: python:amd64 (>= 2.7)
background-packages: 66625
foreground-packages: 1
total-packages: 66626
broken-packages: 1
Given that you seem to work with compatibility level 5, are you sure that you
are working on an up-to-date system? Your bug report says you are on stable but
you seem to be mixing in testing and unstable....
Christian already suggested to use --bd-uninstallable-explainer=apt. If you
don't care about the explainer you can also completely disable it with
--bd-uninstallable-explainer=none.
Thanks!
cheers, josch
signature.asc
Description: signature
