Re: Odd yum 'multilib' error
On Wed, 2013-08-07 at 11:14 +0200, Michael Schwendt wrote: > On Tue, 06 Aug 2013 17:38:15 -0700, Adam Williamson wrote: > > > I just did a 'yum update --skip-broken' on my Rawhide box. the > > skip-broken resolution is pretty complex, it looks like, which is > > probably what causes yum to get its pants in a twist, but the resulting > > 'error' is amusing: > > > > Protected multilib versions: > > libnm-gtk-0.9.9.0-3.git20130515.fc20.x86_64 != > > libnm-gtk-0.9.9.0-2.git20130515.fc20.x86_64 > > > > note: the _same_ arch. It's not a case where it's going to wind up with > > different versions of libnm-gtk for i686 and x86_64; it somehow thinks > > it's going to wind up with two different x86_64 builds installed at once > > and that is a multilib error, or something. > > > > (I only have the x86_64 libnm-gtk installed in the first place, there > > really shouldn't be any multilib considerations here at all). > > > > I've uploaded the complete console output to > > http://www.happyassassin.net/extras/yum.log.gz if anyone's interested. > > Odd. In the log I see _three_ versions of libgm-gtk: > > ---> Package libnm-gtk.x86_64 0:0.9.9.0-2.git20130515.fc20 will be updated > ---> Package libnm-gtk.x86_64 0:0.9.9.0-4.git20130515.fc20 will be an update > > ---> Package nm-connection-editor.x86_64 0:0.9.9.0-2.git20130515.fc20 will be > updated > ---> Package nm-connection-editor.x86_64 0:0.9.9.0-4.git20130515.fc20 will be > an update > > Further down in the log, -3 is chosen as an update after -4 has been chosen > before. > > ---> Package libnm-gtk.x86_64 0:0.9.9.0-3.git20130515.fc20 will be an update > > --> Processing Dependency: libnm-gtk = 0.9.9.0-2.git20130515.fc20 for > package: nm-connection-editor-0.9.9.0-2.git20130515.fc20.x86_64 > ---> Package nm-connection-editor.x86_64 0:0.9.9.0-3.git20130515.fc20 will be > an update > > > >libnm-gtk-0.9.9.0-4.git20130515.fc20.x86_64 from side > > What kind of repo is this "side" repo? > What happens if you disable that repo? It's my local override repository. If I disable it it'll just have more broken dependencies to deal with. The -4 build is this one: http://koji.fedoraproject.org/koji/buildinfo?buildID=454585 which had not made it to Rawhide as of yesterday, which is why I pulled it into my side repo: it's a rebuild for the gnome-bluetooth soname bump. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Odd yum 'multilib' error
On Tue, 06 Aug 2013 17:38:15 -0700, Adam Williamson wrote: > I just did a 'yum update --skip-broken' on my Rawhide box. the > skip-broken resolution is pretty complex, it looks like, which is > probably what causes yum to get its pants in a twist, but the resulting > 'error' is amusing: > > Protected multilib versions: > libnm-gtk-0.9.9.0-3.git20130515.fc20.x86_64 != > libnm-gtk-0.9.9.0-2.git20130515.fc20.x86_64 > > note: the _same_ arch. It's not a case where it's going to wind up with > different versions of libnm-gtk for i686 and x86_64; it somehow thinks > it's going to wind up with two different x86_64 builds installed at once > and that is a multilib error, or something. > > (I only have the x86_64 libnm-gtk installed in the first place, there > really shouldn't be any multilib considerations here at all). > > I've uploaded the complete console output to > http://www.happyassassin.net/extras/yum.log.gz if anyone's interested. Odd. In the log I see _three_ versions of libgm-gtk: ---> Package libnm-gtk.x86_64 0:0.9.9.0-2.git20130515.fc20 will be updated ---> Package libnm-gtk.x86_64 0:0.9.9.0-4.git20130515.fc20 will be an update ---> Package nm-connection-editor.x86_64 0:0.9.9.0-2.git20130515.fc20 will be updated ---> Package nm-connection-editor.x86_64 0:0.9.9.0-4.git20130515.fc20 will be an update Further down in the log, -3 is chosen as an update after -4 has been chosen before. ---> Package libnm-gtk.x86_64 0:0.9.9.0-3.git20130515.fc20 will be an update --> Processing Dependency: libnm-gtk = 0.9.9.0-2.git20130515.fc20 for package: nm-connection-editor-0.9.9.0-2.git20130515.fc20.x86_64 ---> Package nm-connection-editor.x86_64 0:0.9.9.0-3.git20130515.fc20 will be an update >libnm-gtk-0.9.9.0-4.git20130515.fc20.x86_64 from side What kind of repo is this "side" repo? What happens if you disable that repo? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Odd yum 'multilib' error
I just did a 'yum update --skip-broken' on my Rawhide box. the skip-broken resolution is pretty complex, it looks like, which is probably what causes yum to get its pants in a twist, but the resulting 'error' is amusing: Protected multilib versions: libnm-gtk-0.9.9.0-3.git20130515.fc20.x86_64 != libnm-gtk-0.9.9.0-2.git20130515.fc20.x86_64 note: the _same_ arch. It's not a case where it's going to wind up with different versions of libnm-gtk for i686 and x86_64; it somehow thinks it's going to wind up with two different x86_64 builds installed at once and that is a multilib error, or something. (I only have the x86_64 libnm-gtk installed in the first place, there really shouldn't be any multilib considerations here at all). I've uploaded the complete console output to http://www.happyassassin.net/extras/yum.log.gz if anyone's interested. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
