5:09 a.m.
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-sele...
which is kind of annoying. But maybe --force-resolution is worth a try?
Rich.
----- Forwarded message from GitLab <gitlab(a)mg.gitlab.com> -----
Date: Fri, 27 Aug 2021 09:52:55 +0000
From: GitLab <gitlab(a)mg.gitlab.com>
Subject: libnbd | Failed pipeline for master | 2e381ac2
GitLab
✖ Pipeline #360603274 has failed!
Project nbdkit / libnbd
Branch ● master
Commit ● 2e381ac2
interop: Prerequisite qemu-nbd supports TLS Fe...
Commit Author ● Richard W.M. Jones
Pipeline #360603274 triggered by ● Richard W.M. Jones
had 1 failed job.
Failed jobs
✖ containers x64-opensuse-tumbleweed-container
----- End forwarded message -----
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
5:16 a.m.
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-sele...
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 :|
3:29 a.m.
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-sele...
> 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 :|
3:02 a.m.
On Mon, Aug 30, 2021 at 10:29:09AM +0200, Martin Kletzander wrote:
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.
Yes, I notice the issue had "fixed itself" :-/ I guess it's some
transient problem with the OpenSUSE repositories.
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?
I guess we might as well add this option. It'll be hard to know
definitively if it solves the problem. We'll just have to hope that
the problem goes away completely, and add a comment about why the
option seemed to be needed.
Same thing happens in libvirt CI?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
3:43 a.m.
On Tue, Aug 31, 2021 at 09:02:52AM +0100, Richard W.M. Jones wrote:
On Mon, Aug 30, 2021 at 10:29:09AM +0200, Martin Kletzander wrote:
> 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.
Yes, I notice the issue had "fixed itself" :-/ I guess it's some
transient problem with the OpenSUSE repositories.
Yeah, it's just that every now and then there might be some package removed and
then added again fixed but we have higher chance of finding that out since we
check them more often than on a workstation. It happens with Fedora as well
sometimes, it's just a matter of how fast it gets fixed.
> 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?
I guess we might as well add this option. It'll be hard to know
definitively if it solves the problem. We'll just have to hope that
the problem goes away completely, and add a comment about why the
option seemed to be needed.
Same thing happens in libvirt CI?
That was my suggestion - adding this in libvirt CI, so that it is fixed across
all projects. I'll propose the patch and we can discuss there, so that other
interested parties know about the potential change as well.
And dnf+yum have such option too, so I would use that as well, not sure about
the others though.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
1404
days inactive
1408
days old
4 comments
3 participants
participants (3)
-
Daniel P. Berrangé -
Martin Kletzander -
Richard W.M. Jones