[Libguestfs] Fwd: libnbd | Failed pipeline for master | 2e381ac2

[Martin Kletzander]

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>