Daniel P. Berrangé
2021-Aug-27 10:16 UTC
[Libguestfs] Fwd: libnbd | Failed pipeline for master | 2e381ac2
On Fri, Aug 27, 2021 at 11:09:13AM +0100, Richard W.M. Jones wrote:> >From the log: > https://gitlab.com/nbdkit/libnbd/-/jobs/1540375264 > > opensuse zypper seems to be failing with a recoverable error: > > Resolving package dependencies... > Problem: the to be installed glib2-devel-2.68.3-4.1.x86_64 requires 'libglib-2_0-0 = 2.68.3', but this requirement cannot be provided > not installable providers: libglib-2_0-0-2.68.3-4.1.i586[repo-oss] > libglib-2_0-0-2.68.3-4.1.x86_64[repo-oss] > Solution 1: downgrade of libglib-2_0-0-2.68.4-1.1.x86_64 to libglib-2_0-0-2.68.3-4.1.x86_64 > Solution 2: do not install glib2-devel-2.68.3-4.1.x86_64 > Solution 3: break glib2-devel-2.68.3-4.1.x86_64 by ignoring some of its dependencies > Choose from above solutions by number or cancel [1/2/3/c/d/?] (c): c > > I wonder if this is something that libvirt-ci should handle better? > > I found this thread which seems to indicate there's no way to force > zypper to pick an option: > https://www.linuxquestions.org/questions/suse-opensuse-60/how-to-pre-select-solutions-1-or-2-in-autoyast-xml-config-file-4175688006/ > which is kind of annoying. But maybe --force-resolution is worth a try?I've not tried that option, but I will say that openSuse Tumbleweed seems to hit these broken dependancy problems fairly often. I'm increasingly inclined to say it is too unstable to be worth having in CI, unless it is marked "allow_failure: true" so it doesn't block the pipeline Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
Martin Kletzander
2021-Aug-30 08:29 UTC
[Libguestfs] Fwd: libnbd | Failed pipeline for master | 2e381ac2
On Fri, Aug 27, 2021 at 11:16:25AM +0100, Daniel P. Berrang? wrote:>On Fri, Aug 27, 2021 at 11:09:13AM +0100, Richard W.M. Jones wrote: >> >From the log: >> https://gitlab.com/nbdkit/libnbd/-/jobs/1540375264 >> >> opensuse zypper seems to be failing with a recoverable error: >> >> Resolving package dependencies... >> Problem: the to be installed glib2-devel-2.68.3-4.1.x86_64 requires 'libglib-2_0-0 = 2.68.3', but this requirement cannot be provided >> not installable providers: libglib-2_0-0-2.68.3-4.1.i586[repo-oss] >> libglib-2_0-0-2.68.3-4.1.x86_64[repo-oss] >> Solution 1: downgrade of libglib-2_0-0-2.68.4-1.1.x86_64 to libglib-2_0-0-2.68.3-4.1.x86_64 >> Solution 2: do not install glib2-devel-2.68.3-4.1.x86_64 >> Solution 3: break glib2-devel-2.68.3-4.1.x86_64 by ignoring some of its dependencies >> Choose from above solutions by number or cancel [1/2/3/c/d/?] (c): c >> >> I wonder if this is something that libvirt-ci should handle better? >> >> I found this thread which seems to indicate there's no way to force >> zypper to pick an option: >> https://www.linuxquestions.org/questions/suse-opensuse-60/how-to-pre-select-solutions-1-or-2-in-autoyast-xml-config-file-4175688006/ >> which is kind of annoying. But maybe --force-resolution is worth a try? > >I've not tried that option, but I will say that openSuse Tumbleweed >seems to hit these broken dependancy problems fairly often. I'm >increasingly inclined to say it is too unstable to be worth having >in CI, unless it is marked "allow_failure: true" so it doesn't >block the pipeline >I actually had an idea for that. There is an option despite what is in the link (as that one is slightly unrelated I think). I was thinking earlier about adding --allow-downgrade to all zypper install invocations in libvirt-ci, but by the time I got to writing the patch it fixed itself and I could not reproduce it. Just like now with this issue. There are couple more "Expert options" but I did not think very hard about using the other ones. Anyway, here's the list: --allow-downgrade --no-allow-downgrade Whether to allow downgrading installed resolvables. --allow-name-change --no-allow-name-change Whether to allow changing the names of installed resolvables. --allow-arch-change --no-allow-arch-change Whether to allow changing the architecture of installed resolvables. --allow-vendor-change --no-allow-vendor-change Whether to allow changing the vendor of installed resolvables. Should I write the patch for --allow-downgrade? Martin> >Regards, >Daniel >-- >|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| >|: https://libvirt.org -o- https://fstop138.berrange.com :| >|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| >-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://listman.redhat.com/archives/libguestfs/attachments/20210830/2fa6c213/attachment.sig>