Bug#964026: libelogind0: `Provides: libsystemd0` causes unrelated packages to fail to build (unmet dependencies)
Control: tag -1 + patch Hi Jessica, Quoting Jessica Clarke (2020-07-12 00:54:53) > Is this not the bug I fixed a while ago and you committed upstream > recently[1]? There hasn't been a dose3 upload to Debian yet with that fixed. > > Jess > > [1] > https://scm.gforge.inria.fr/anonscm/gitweb?p=dose/dose.git;a=commitdiff;h=226e7eb544bd02b128c19be5e79a9b236439159f you are correct! With that patch, apt-cudf produces the correct conflicts field. I'll talk with Ralf about the next release. Thanks!! :) cheers, josch signature.asc Description: signature
Bug#964026: libelogind0: `Provides: libsystemd0` causes unrelated packages to fail to build (unmet dependencies)
On 11 Jul 2020, at 23:47, Johannes Schauer wrote: > > Hi, > > I put Jessica and Ralf in CC because they are the solver experts. :) > > On Wed, 8 Jul 2020 18:27:54 +0200 Adam Borowski wrote: >> This problem can't possibly be caused by elogind. A package may cause a >> problem only if: >> 1. some of its code is actually run (preinst, postinst, payload), or >> 2. it's the first alternative and the solver uses "first alternative only" >> or is otherwise unable to use the full solutions space >> >> The docs say: >>'aspcud' resolver which (in contrast to apt and aptitude) is a real >>solver (in the math sense) and will thus always find a solution if a >>solution exists. >> >> Given a set of packages A containing package X, if A - X contains a >> solution, A with X also does -- ie, no relations declared by X (Breaks, >> Conflicts, Depends, Provides, ...) may possibly invalidate that solution. >> >> And we have: >> * unstable: apt resolver, doesn't even consider libelogind0 >> * experimental: aspcud, supposed to be a full solver >> >> Thus, it looks to me like a problem in apt-cudf, almost surely not in the >> solver itself but in its integration with apt. > > I managed to find out where the problem comes from. The problem is indeed not > aspcud but apt-cudf. Apt transforms the problem into the EDSP format, and > libelogind0 looks like this: > > Package: libelogind0 > Architecture: amd64 > Version: 243.7-1+debian1 > APT-ID: 7784 > Multi-Arch: same > Source: elogind > Source-Version: 243.7-1+debian1 > Priority: optional > Section: libs > APT-Release: > o=Debian,a=unstable,n=sid,l=Debian,c=main,b=amd64 > APT-Pin: 500 > APT-Candidate: yes > Depends: libc6 (>= 2.30), libcap2 (>= 1:2.10) > Conflicts: libsystemd0, systemd > Replaces: libsystemd0 > Provides: libsystemd0 (= 243.7) > > That's all good and seems fine. It is then the job of apt-cudf to turn the > EDSP > format into CUDF format which is understood by common CUDF solvers. And that's > where things go wrong, because the CUDF stanza for libelogind0 reads: > > package: libelogind0%3aamd64 > version: 23683 > depends: libc6%3aamd64 >= 16972 , libcap2%3aamd64 >= 25386 > conflicts: systemd%3aamd64 , --virtual-systemd%3aamd64 , systemd%3aamd64 , > --virtual-systemd%3aamd64 , libelogind0%3aamd64 > provides: libelogind0 , --virtual--versioned-libsystemd0%3aamd64 = 23682 , > --virtual-libsystemd0%3aamd64 = 2147483646 > installed: true > priority: optional > name: libelogind0 > architecture: amd64 > number: 243.7-1+debian1 > source: elogind > sourcenumber: 243.7-1+debian1 > sourceversion: 23683 > replaces: libsystemd0 , --virtual-libsystemd0 > native: 1 > type: bin > apt-pin: 500 > apt-id: 7784 > apt-candidate: true > section: libs > > Looking into the conflicts field, the conflict with libsystemd0 doesn't exist > anymore. This explains why aspcud happily adds libelogind0 into the solution: > because it wasn't told, that it conflicts with libsystemd0. If you want to > find > out the above at home, just run sbuild with --build-deps-failed-commands=%s > like so: > >$ sbuild -d unstable --extra-repository='deb http://deb.debian.org/debian > experimental main' --extra-repository='deb-src http://deb.debian.org/debian > experimental main' --build-dep-resolver=aspcud > --build-deps-failed-commands=%s hplip_3.20.6+dfsg0-1 > > and then after build-deps failed to install, run the following to create an > EDSP file: > >$ APT_EDSP_DUMP_FILENAME=/tmp/dump.edsp apt-get install > --with-source=resolver-* --simulate --solver=dump -o > APT::Solver::Strict-Pinning=false sbuild-build-depends-main-dummy > > You can then copy the EDSP file out of the schroot and put it into apt-cudf: > >$ apt-cudf -v --solver=aspcud -c > "-count(solution,APT-Release:=/a=experimental/),-removed,-changed,-new" > /tmp/dump.edsp --dump > > Using the --dump option you can also see the cudf translation. To save you the > trouble, I put the EDSP file as an attachment to this mail. > > Thanks! > > cheers, josch Is this not the bug I fixed a while ago and you committed upstream recently[1]? There hasn't been a dose3 upload to Debian yet with that fixed. Jess [1] https://scm.gforge.inria.fr/anonscm/gitweb?p=dose/dose.git;a=commitdiff;h=226e7eb544bd02b128c19be5e79a9b236439159f
Bug#964026: libelogind0: `Provides: libsystemd0` causes unrelated packages to fail to build (unmet dependencies)
Hi, I put Jessica and Ralf in CC because they are the solver experts. :) On Wed, 8 Jul 2020 18:27:54 +0200 Adam Borowski wrote: > This problem can't possibly be caused by elogind. A package may cause a > problem only if: > 1. some of its code is actually run (preinst, postinst, payload), or > 2. it's the first alternative and the solver uses "first alternative only" >or is otherwise unable to use the full solutions space > > The docs say: > 'aspcud' resolver which (in contrast to apt and aptitude) is a real > solver (in the math sense) and will thus always find a solution if a > solution exists. > > Given a set of packages A containing package X, if A - X contains a > solution, A with X also does -- ie, no relations declared by X (Breaks, > Conflicts, Depends, Provides, ...) may possibly invalidate that solution. > > And we have: > * unstable: apt resolver, doesn't even consider libelogind0 > * experimental: aspcud, supposed to be a full solver > > Thus, it looks to me like a problem in apt-cudf, almost surely not in the > solver itself but in its integration with apt. I managed to find out where the problem comes from. The problem is indeed not aspcud but apt-cudf. Apt transforms the problem into the EDSP format, and libelogind0 looks like this: Package: libelogind0 Architecture: amd64 Version: 243.7-1+debian1 APT-ID: 7784 Multi-Arch: same Source: elogind Source-Version: 243.7-1+debian1 Priority: optional Section: libs APT-Release: o=Debian,a=unstable,n=sid,l=Debian,c=main,b=amd64 APT-Pin: 500 APT-Candidate: yes Depends: libc6 (>= 2.30), libcap2 (>= 1:2.10) Conflicts: libsystemd0, systemd Replaces: libsystemd0 Provides: libsystemd0 (= 243.7) That's all good and seems fine. It is then the job of apt-cudf to turn the EDSP format into CUDF format which is understood by common CUDF solvers. And that's where things go wrong, because the CUDF stanza for libelogind0 reads: package: libelogind0%3aamd64 version: 23683 depends: libc6%3aamd64 >= 16972 , libcap2%3aamd64 >= 25386 conflicts: systemd%3aamd64 , --virtual-systemd%3aamd64 , systemd%3aamd64 , --virtual-systemd%3aamd64 , libelogind0%3aamd64 provides: libelogind0 , --virtual--versioned-libsystemd0%3aamd64 = 23682 , --virtual-libsystemd0%3aamd64 = 2147483646 installed: true priority: optional name: libelogind0 architecture: amd64 number: 243.7-1+debian1 source: elogind sourcenumber: 243.7-1+debian1 sourceversion: 23683 replaces: libsystemd0 , --virtual-libsystemd0 native: 1 type: bin apt-pin: 500 apt-id: 7784 apt-candidate: true section: libs Looking into the conflicts field, the conflict with libsystemd0 doesn't exist anymore. This explains why aspcud happily adds libelogind0 into the solution: because it wasn't told, that it conflicts with libsystemd0. If you want to find out the above at home, just run sbuild with --build-deps-failed-commands=%s like so: $ sbuild -d unstable --extra-repository='deb http://deb.debian.org/debian experimental main' --extra-repository='deb-src http://deb.debian.org/debian experimental main' --build-dep-resolver=aspcud --build-deps-failed-commands=%s hplip_3.20.6+dfsg0-1 and then after build-deps failed to install, run the following to create an EDSP file: $ APT_EDSP_DUMP_FILENAME=/tmp/dump.edsp apt-get install --with-source=resolver-* --simulate --solver=dump -o APT::Solver::Strict-Pinning=false sbuild-build-depends-main-dummy You can then copy the EDSP file out of the schroot and put it into apt-cudf: $ apt-cudf -v --solver=aspcud -c "-count(solution,APT-Release:=/a=experimental/),-removed,-changed,-new" /tmp/dump.edsp --dump Using the --dump option you can also see the cudf translation. To save you the trouble, I put the EDSP file as an attachment to this mail. Thanks! cheers, josch signature.asc Description: signature
Bug#964026: libelogind0: `Provides: libsystemd0` causes unrelated packages to fail to build (unmet dependencies)
On Wed, Jul 08, 2020 at 03:44:21PM +0200, Ansgar wrote: > On Wed, 2020-07-08 at 11:04 +0200, Johannes Schauer wrote: > > What is happening here is, that aspcud chooses libelogind0 for installation > > and > > then apt decides that it refuses to install it because it doesn't want to > > remove libsystemd0 in favor of libelogind0 and by that replace an important > > package (apt would require the "yes, do as I say!" thing for that to work). > > libsystemd0 doesn't seem special though? It's `Priority: optional` and > doesn't have much else; I guess trying to uninstall libsystemd0 breaks > something else? > > I'm not really motivated to debug problems caused by elogind though. This problem can't possibly be caused by elogind. A package may cause a problem only if: 1. some of its code is actually run (preinst, postinst, payload), or 2. it's the first alternative and the solver uses "first alternative only" or is otherwise unable to use the full solutions space The docs say: 'aspcud' resolver which (in contrast to apt and aptitude) is a real solver (in the math sense) and will thus always find a solution if a solution exists. Given a set of packages A containing package X, if A - X contains a solution, A with X also does -- ie, no relations declared by X (Breaks, Conflicts, Depends, Provides, ...) may possibly invalidate that solution. And we have: * unstable: apt resolver, doesn't even consider libelogind0 * experimental: aspcud, supposed to be a full solver Thus, it looks to me like a problem in apt-cudf, almost surely not in the solver itself but in its integration with apt. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. ⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi ⠈⠳⣄
Bug#964026: libelogind0: `Provides: libsystemd0` causes unrelated packages to fail to build (unmet dependencies)
On Wed, 2020-07-08 at 11:04 +0200, Johannes Schauer wrote: > What is happening here is, that aspcud chooses libelogind0 for installation > and > then apt decides that it refuses to install it because it doesn't want to > remove libsystemd0 in favor of libelogind0 and by that replace an important > package (apt would require the "yes, do as I say!" thing for that to work). libsystemd0 doesn't seem special though? It's `Priority: optional` and doesn't have much else; I guess trying to uninstall libsystemd0 breaks something else? I'm not really motivated to debug problems caused by elogind though. > But instead of re-assigning this to apt for ignoring part of the installation > request by apt-cudf, maybe we can solve this differently. > > Ansgar, can you tell me which preferences you pass for experimental > installations on the buildds? I don't know what buildds use, but I could reproduce the problem locally with sbuild without setting anything special. Ansgar
Bug#964026: libelogind0: `Provides: libsystemd0` causes unrelated packages to fail to build (unmet dependencies)
Hi, On Fri, 3 Jul 2020 15:36:56 +0100 Mark Hindley wrote: > On Tue, Jun 30, 2020 at 07:43:52PM +0200, Ansgar wrote: > > On Tue, 2020-06-30 at 17:45 +0100, Mark Hindley wrote: > > > I am struggling to understand how libelogind0 came to be installed in the > > > build > > > in the first place. Can you help me understand that? > > > > No idea; apt's resolver is sometimes creative. Other examples include > > [1], [2], [3]. > > > > [1]: > > https://buildd.debian.org/status/logs.php?pkg=hplip=3.20.6%2Bdfsg0-1=amd64 > > [2]: > > https://buildd.debian.org/status/logs.php?pkg=gnome-applets=3.37.2-1=amd64 > > [3]: > > https://buildd.debian.org/status/logs.php?pkg=kopete=4%3A20.04.1-1=amd64 > > The common feature in all of these experimental buildd failures is that > apt-cudf > fails to find the correct solution leaving a libsystemd-dev <=> libelogind0 > conflict. What is happening here is, that aspcud chooses libelogind0 for installation and then apt decides that it refuses to install it because it doesn't want to remove libsystemd0 in favor of libelogind0 and by that replace an important package (apt would require the "yes, do as I say!" thing for that to work). But instead of re-assigning this to apt for ignoring part of the installation request by apt-cudf, maybe we can solve this differently. Ansgar, can you tell me which preferences you pass for experimental installations on the buildds? I'm looking for the APT::Solver::aspcud::Preferences setting that is used by sbuild. It might be possible to tweak this setting such that aspcud can find a solution that does not changing Essential:yes packages. Thanks! cheers, josch signature.asc Description: signature
Bug#964026: libelogind0: `Provides: libsystemd0` causes unrelated packages to fail to build (unmet dependencies)
Control: reassign -1 apt-cudf Dear apt-cudf maintainers, On Tue, Jun 30, 2020 at 07:43:52PM +0200, Ansgar wrote: > On Tue, 2020-06-30 at 17:45 +0100, Mark Hindley wrote: > > I am struggling to understand how libelogind0 came to be installed in the > > build > > in the first place. Can you help me understand that? > > No idea; apt's resolver is sometimes creative. Other examples include > [1], [2], [3]. > > [1]: > https://buildd.debian.org/status/logs.php?pkg=hplip=3.20.6%2Bdfsg0-1=amd64 > [2]: > https://buildd.debian.org/status/logs.php?pkg=gnome-applets=3.37.2-1=amd64 > [3]: > https://buildd.debian.org/status/logs.php?pkg=kopete=4%3A20.04.1-1=amd64 The common feature in all of these experimental buildd failures is that apt-cudf fails to find the correct solution leaving a libsystemd-dev <=> libelogind0 conflict. Reassiging. Thanks. Mark
Bug#964026: libelogind0: `Provides: libsystemd0` causes unrelated packages to fail to build (unmet dependencies)
On Thu, 2 Jul 2020, Ansgar wrote: > It doesn't as you can see. In reality dependencies don't work as > simple as "apt will always pick the first choice". I think this is still true for all distributions except experimental. But yes, talk to the package managers’ maintainers. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Bug#964026: libelogind0: `Provides: libsystemd0` causes unrelated packages to fail to build (unmet dependencies)
On Thu, 2020-07-02 at 16:34 +0100, Mark Hindley wrote: > On Thu, Jul 02, 2020 at 04:33:36PM +0200, Thorsten Glaser wrote: > > On Thu, 2 Jul 2020, Ansgar wrote: > > > package), so the problem might also be the `Provides: logind` in > > > libpam-elogind. > > > > Shouldn’t the package dependencies on default-logind | logind > > handle this? > > Absolutely. It doesn't as you can see. In reality dependencies don't work as simple as "apt will always pick the first choice". > Nothing you have shown so far demonstrates anything wrong with the > src:elogind > dependencies. In fact you have suggested several times that this is an issue > with apt or whatever dependency resolver the experimental buildd uses. If you manage to fix this in the dependency resolver that's also fine; I don't care much how this is fixed, but I believe that packages should be buildable without manual intervention. In general satisfying dependencies seems to be a complicated problem and resolvers will sometimes not be able to find a desired solution. Changing dependencies in those cases is fine and (as far as I know) has been done previously for other cases. > Can you provide information from the resolver to show how it is > coming to its incorrect decision? I'm not an expert on dependency resolvers, no. Ansgar
Bug#964026: libelogind0: `Provides: libsystemd0` causes unrelated packages to fail to build (unmet dependencies)
Control: tags -1 moreinfo On Thu, Jul 02, 2020 at 04:33:36PM +0200, Thorsten Glaser wrote: > On Thu, 2 Jul 2020, Ansgar wrote: > > > package), so the problem might also be the `Provides: logind` in > > libpam-elogind. > > Shouldn’t the package dependencies on default-logind | logind > handle this? Absolutely. Ansgar, Nothing you have shown so far demonstrates anything wrong with the src:elogind dependencies. In fact you have suggested several times that this is an issue with apt or whatever dependency resolver the experimental buildd uses. Can you provide information from the resolver to show how it is coming to its incorrect decision? Thanks Mark
Bug#964026: libelogind0: `Provides: libsystemd0` causes unrelated packages to fail to build (unmet dependencies)
On Thu, 2 Jul 2020, Ansgar wrote: > package), so the problem might also be the `Provides: logind` in > libpam-elogind. Shouldn’t the package dependencies on default-logind | logind handle this? Weird… bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#964026: libelogind0: `Provides: libsystemd0` causes unrelated packages to fail to build (unmet dependencies)
Control: tag -1 - moreinfo On Thu, 2020-07-02 at 12:58 +0100, Mark Hindley wrote: > On Wed, Jul 01, 2020 at 12:35:18PM +0200, Axel Beckert wrote: > > Is it still the case that the buildds use aptitude for resolving > > dependencies on experimental builds? Because aptitude might be even > > more "creative" than apt in that regards. They use a different resolver as indicated in the log. There are other small differences too between unstable and experimental (or backports which has similar differences IIRC). > Thanks. That is one for Angar. > > It seems possible that the presence of libpam-elogind-compat in experimental > makes aptitude and/or apt try an invalid solution. No; at least adding a build-conflict on libpam-elogind-compat doesn't change the result. Adding a build-conflict on elogind or libpam-elogind instead of libelogind0 works too (as least with "kopete"; did only test that one package), so the problem might also be the `Provides: logind` in libpam-elogind. Ansgar
Bug#964026: libelogind0: `Provides: libsystemd0` causes unrelated packages to fail to build (unmet dependencies)
Control: tags -1 moreinfo On Wed, Jul 01, 2020 at 12:35:18PM +0200, Axel Beckert wrote: > Is it still the case that the buildds use aptitude for resolving > dependencies on experimental builds? Because aptitude might be even > more "creative" than apt in that regards. Thanks. That is one for Angar. It seems possible that the presence of libpam-elogind-compat in experimental makes aptitude and/or apt try an invalid solution. Ansgar, are you able to confirm that? If so I will reassign. libpam-elogind-compat can be removed completely once packages update dependencies from libpam-systemd to default-logind | logind. The outstanding bugs that I am aware of are #925338, #925339, #932047 #921021, #923387 (the last 2 of which I see have been closed unanswered). Mark
Bug#964026: libelogind0: `Provides: libsystemd0` causes unrelated packages to fail to build (unmet dependencies)
Hi, Mark Hindley wrote: > > > I am struggling to understand how libelogind0 came to be installed in the > > > build > > > in the first place. Can you help me understand that? > > > > No idea; apt's resolver is sometimes creative. Other examples include > > [1], [2], [3]. > > > > [1]: > > https://buildd.debian.org/status/logs.php?pkg=hplip=3.20.6%2Bdfsg0-1=amd64 > > [2]: > > https://buildd.debian.org/status/logs.php?pkg=gnome-applets=3.37.2-1=amd64 > > [3]: > > https://buildd.debian.org/status/logs.php?pkg=kopete=4%3A20.04.1-1=amd64 > > Thanks. I have looked through these and, again, I can see no other regerences > to > either elogind or systemd that might explain this. > > However, all 4 examples you have given relate to builds for > experimental. Is it still the case that the buildds use aptitude for resolving dependencies on experimental builds? Because aptitude might be even more "creative" than apt in that regards. 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#964026: libelogind0: `Provides: libsystemd0` causes unrelated packages to fail to build (unmet dependencies)
Ansgar, On Tue, Jun 30, 2020 at 07:43:52PM +0200, Ansgar wrote: > On Tue, 2020-06-30 at 17:45 +0100, Mark Hindley wrote: > > I am struggling to understand how libelogind0 came to be installed in the > > build > > in the first place. Can you help me understand that? > > No idea; apt's resolver is sometimes creative. Other examples include > [1], [2], [3]. > > [1]: > https://buildd.debian.org/status/logs.php?pkg=hplip=3.20.6%2Bdfsg0-1=amd64 > [2]: > https://buildd.debian.org/status/logs.php?pkg=gnome-applets=3.37.2-1=amd64 > [3]: > https://buildd.debian.org/status/logs.php?pkg=kopete=4%3A20.04.1-1=amd64 Thanks. I have looked through these and, again, I can see no other regerences to either elogind or systemd that might explain this. However, all 4 examples you have given relate to builds for experimental. Is that always the case? If so, I wonder if this is related to the presence in experimental of libpam-elogind-compat? Mark
Bug#964026: libelogind0: `Provides: libsystemd0` causes unrelated packages to fail to build (unmet dependencies)
On Tue, 2020-06-30 at 17:45 +0100, Mark Hindley wrote: > I am struggling to understand how libelogind0 came to be installed in the > build > in the first place. Can you help me understand that? No idea; apt's resolver is sometimes creative. Other examples include [1], [2], [3]. [1]: https://buildd.debian.org/status/logs.php?pkg=hplip=3.20.6%2Bdfsg0-1=amd64 [2]: https://buildd.debian.org/status/logs.php?pkg=gnome-applets=3.37.2-1=amd64 [3]: https://buildd.debian.org/status/logs.php?pkg=kopete=4%3A20.04.1-1=amd64 > Presumably there is a build dependency on libsystemd-dev, but I don't see it > in > the log. That's probably not required for apt to find the unwanted solution. Ansgar
Bug#964026: libelogind0: `Provides: libsystemd0` causes unrelated packages to fail to build (unmet dependencies)
Ansgar, Thanks for this. On Tue, Jun 30, 2020 at 06:27:20PM +0200, Ansgar wrote: > Package: libelogind0 > Version: 243.7-1+debian1 > Severity: serious > > libelogind0's `Provides: libsystemd0` causes unrelated packages to > fail to build due to unmet dependencies. See [1] for an example. > > The relevant log part is: > > +--- > | The following packages have unmet dependencies: > | libelogind0 : Conflicts: libsystemd0 > | E: Broken packages > | apt-get failed. > +--- I am struggling to understand how libelogind0 came to be installed in the build in the first place. Can you help me understand that? Presumably there is a build dependency on libsystemd-dev, but I don't see it in the log. Thanks Mark
Bug#964026: libelogind0: `Provides: libsystemd0` causes unrelated packages to fail to build (unmet dependencies)
Package: libelogind0 Version: 243.7-1+debian1 Severity: serious libelogind0's `Provides: libsystemd0` causes unrelated packages to fail to build due to unmet dependencies. See [1] for an example. The relevant log part is: +--- | The following packages have unmet dependencies: | libelogind0 : Conflicts: libsystemd0 | E: Broken packages | apt-get failed. +--- Other packages are also affected. Currently the w-b team sometimes adds manual build conflicts against libelogind0 to work around the issue, but that is not really a sustainable solution. Ansgar [1]: https://buildd.debian.org/status/logs.php?pkg=libreoffice=1%3A7.0.0%7Ebeta2-2=amd64=experimental
