persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs

[Jurgen Kramer]

I have not seen any mention of this on the list so far so here it goes.
I've been seeing gnome dep problems for the last few days (through alpha
rc's and now alpha).

I managed to get a lot of updates installed by selectively install
updates. When I try to workaround the remaining dep problems yum wants
to get i686 libs...

--> Finished Dependency Resolution
Error: Package: evolution-NetworkManager-3.1.4-1.fc16.x86_64
(@anaconda-0)
           Requires: libecal-1.2.so.9()(64bit)
           Removing: evolution-data-server-3.1.4-1.fc16.x86_64
(@anaconda-0)
               libecal-1.2.so.9()(64bit)
           Updated By: evolution-data-server-3.1.5-2.fc16.x86_64
(updates-testing)
               Not found
Error: Package: 1:nautilus-sendto-3.0.0-6.fc16.x86_64 (@anaconda-0)
           Requires: libedataserver-1.2.so.14()(64bit)
           Removing: evolution-data-server-3.1.4-1.fc16.x86_64
(@anaconda-0)
               libedataserver-1.2.so.14()(64bit)
           Updated By: evolution-data-server-3.1.5-2.fc16.x86_64
(updates-testing)
               Not found
Error: Package: evolution-3.1.4-1.fc16.x86_64 (@anaconda-0)
           Requires: libecal-1.2.so.9()(64bit)
           Removing: evolution-data-server-3.1.4-1.fc16.x86_64
(@anaconda-0)
               libecal-1.2.so.9()(64bit)
           Updated By: evolution-data-server-3.1.5-2.fc16.x86_64
(updates-testing)
               Not found
Error: Package: evolution-NetworkManager-3.1.4-1.fc16.x86_64
(@anaconda-0)
           Requires: libedataserver-1.2.so.14()(64bit)
           Removing: evolution-data-server-3.1.4-1.fc16.x86_64
(@anaconda-0)
               libedataserver-1.2.so.14()(64bit)
           Updated By: evolution-data-server-3.1.5-2.fc16.x86_64
(updates-testing)
               Not found
Error: Package: evolution-3.1.4-1.fc16.x86_64 (@anaconda-0)
           Requires: libebook-1.2.so.11()(64bit)
           Removing: evolution-data-server-3.1.4-1.fc16.x86_64
(@anaconda-0)
               libebook-1.2.so.11()(64bit)
           Updated By: evolution-data-server-3.1.5-2.fc16.x86_64
(updates-testing)
               Not found
Error: Package: evolution-NetworkManager-3.1.4-1.fc16.x86_64
(@anaconda-0)
           Requires: libebook-1.2.so.11()(64bit)
           Removing: evolution-data-server-3.1.4-1.fc16.x86_64
(@anaconda-0)
               libebook-1.2.so.11()(64bit)
           Updated By: evolution-data-server-3.1.5-2.fc16.x86_64
(updates-testing)
               Not found
Error: Package: evolution-3.1.4-1.fc16.x86_64 (@anaconda-0)
           Requires: libedataserver-1.2.so.14()(64bit)
           Removing: evolution-data-server-3.1.4-1.fc16.x86_64
(@anaconda-0)
               libedataserver-1.2.so.14()(64bit)
           Updated By: evolution-data-server-3.1.5-2.fc16.x86_64
(updates-testing)
               Not found
Error: Package: 1:nautilus-sendto-3.0.0-6.fc16.x86_64 (@anaconda-0)
           Requires: libebook-1.2.so.11()(64bit)
           Removing: evolution-data-server-3.1.4-1.fc16.x86_64
(@anaconda-0)
               libebook-1.2.so.11()(64bit)
           Updated By: evolution-data-server-3.1.5-2.fc16.x86_64
(updates-testing)
               Not found
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

When I try --skip-broken I get:

[root@develbox ~]# yum update --skip-broken
Loaded plugins: langpacks, presto, refresh-packagekit
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package control-center.x86_64 1:3.1.4-1.fc16 will be updated
---> Package control-center.x86_64 1:3.1.5-3.fc16 will be an update
---> Package control-center-filesystem.x86_64 1:3.1.4-1.fc16 will be
updated
---> Package control-center-filesystem.x86_64 1:3.1.5-3.fc16 will be an
update
---> Package empathy.x86_64 0:3.1.4-1.fc16 will be updated
---> Package empathy.x86_64 0:3.1.5.1-1.fc16 will be an update
--> Processing Dependency: libp11-kit.so.0()(64bit) for package:
empathy-3.1.5.1-1.fc16.x86_64
---> Package evolution-data-server.x86_64 0:3.1.4-1.fc16 will be updated
--> Processing Dependency: libebook-1.2.so.11()(64bit) for package:
evolution-NetworkManager-3.1.4-1.fc16.x86_64
--> Processing Dependency: libebook-1.2.so.11()(64bit) for package:
1:nautilus-sendto-3.0.0-6.fc16.x86_64
--> Processing Dependency: libebook-1.2.so.11()(64bit) for package:
evolution-3.1.4-1.fc16.x86_64
--> Processing Dependency: libecal-1.2.so.9()(64bit) for package:
evolution-NetworkManager-3.1.4-1.fc16.x86_64
--> Processing Dependency: libecal-1.2.so.9()(64bit) for package:
evolution-3.1.4-1.fc16.x86_64
--> Processing Dependency: libedataserver-1.2.so.14()(64bit) for
package: evolution-NetworkManager-3.1.4-1.fc16.x86_64
--> Processing Dependency: libedataserver-1.2.so.14()(64bit) for
package: 1:nautilus-sendto-3.0.0-6.fc16.x86_64
--> Processing Dependency: libedataserver-1.2.so.14()(64bit) for
package: evolution-3.1.4-1.fc16.x86_64
---> Package evolution-data-server.x86_64 0:3.1.5-2.fc16 will be an
update
---> Package folks.x86_64 1:0.5.2-1.fc16 will be updated
---> Package folks.x86_64 1:0.6.0-5.fc16 will be an update
--> Processing Dependency: libsocialweb-client.so.2()(64bit) for
package: 1:folks-0.6.0-5.fc16.x86_64
---> Package gnome-contacts.x86_64 0:0.1.1-1.fc16 will be updated
---> Package gnome-contacts.x86_64 0:0.1.2-2.fc16 will be an update
---> Package gnome-keyring.x86_64 0:3.1.1-2.fc16 will be updated
---> Package gnome-keyring.x86_64 0:3.1.4-1.fc16 will be an update
---> Package gnome-keyring-pam.x86_64 0:3.1.1-2.fc16 will be updated
---> Package gnome-keyring-pam.x86_64 0:3.1.4-1.fc16 will be an update
---> Package gnome-menus.x86_64 0:3.0.1-1.fc16 will be updated
---> Package gnome-menus.x86_64 0:3.1.5-2.fc16 will be an update
---> Package gnome-panel.x86_64 0:3.0.2-3.fc16 will be updated
---> Package gnome-panel.x86_64 0:3.1.5-2.fc16 will be an update
---> Package gnome-panel-libs.x86_64 0:3.0.2-3.fc16 will be updated
---> Package gnome-panel-libs.x86_64 0:3.1.5-2.fc16 will be an update
---> Package gnome-session.x86_64 0:3.1.3-1.fc16 will be updated
---> Package gnome-session.x86_64 0:3.1.5-1.fc16 will be an update
---> Package gnome-session-xsession.x86_64 0:3.1.3-1.fc16 will be
updated
---> Package gnome-session-xsession.x86_64 0:3.1.5-1.fc16 will be an
update
---> Package gnome-shell.x86_64 0:3.1.4-1.fc16 will be updated
---> Package gnome-shell.x86_64 0:3.1.4-2.gite7b9933.fc16 will be an
update
--> Running transaction check
---> Package evolution-data-server.x86_64 0:3.1.4-1.fc16 will be updated
--> Processing Dependency: libebook-1.2.so.11()(64bit) for package:
evolution-NetworkManager-3.1.4-1.fc16.x86_64
--> Processing Dependency: libebook-1.2.so.11()(64bit) for package:
1:nautilus-sendto-3.0.0-6.fc16.x86_64
--> Processing Dependency: libebook-1.2.so.11()(64bit) for package:
evolution-3.1.4-1.fc16.x86_64
--> Processing Dependency: libecal-1.2.so.9()(64bit) for package:
evolution-NetworkManager-3.1.4-1.fc16.x86_64
--> Processing Dependency: libecal-1.2.so.9()(64bit) for package:
evolution-3.1.4-1.fc16.x86_64
--> Processing Dependency: libedataserver-1.2.so.14()(64bit) for
package: evolution-NetworkManager-3.1.4-1.fc16.x86_64
--> Processing Dependency: libedataserver-1.2.so.14()(64bit) for
package: 1:nautilus-sendto-3.0.0-6.fc16.x86_64
--> Processing Dependency: libedataserver-1.2.so.14()(64bit) for
package: evolution-3.1.4-1.fc16.x86_64
---> Package libsocialweb.x86_64 0:0.25.19-1.fc16 will be installed
--> Processing Dependency: libsocialweb-keys = 0.25.19-1.fc16 for
package: libsocialweb-0.25.19-1.fc16.x86_64
---> Package p11-kit.x86_64 0:0.4-1.fc16 will be installed
--> Running transaction check
---> Package evolution-data-server.x86_64 0:3.1.4-1.fc16 will be updated
--> Processing Dependency: libebook-1.2.so.11()(64bit) for package:
evolution-NetworkManager-3.1.4-1.fc16.x86_64
--> Processing Dependency: libebook-1.2.so.11()(64bit) for package:
1:nautilus-sendto-3.0.0-6.fc16.x86_64
--> Processing Dependency: libebook-1.2.so.11()(64bit) for package:
evolution-3.1.4-1.fc16.x86_64
--> Processing Dependency: libecal-1.2.so.9()(64bit) for package:
evolution-NetworkManager-3.1.4-1.fc16.x86_64
--> Processing Dependency: libecal-1.2.so.9()(64bit) for package:
evolution-3.1.4-1.fc16.x86_64
--> Processing Dependency: libedataserver-1.2.so.14()(64bit) for
package: evolution-NetworkManager-3.1.4-1.fc16.x86_64
--> Processing Dependency: libedataserver-1.2.so.14()(64bit) for
package: 1:nautilus-sendto-3.0.0-6.fc16.x86_64
--> Processing Dependency: libedataserver-1.2.so.14()(64bit) for
package: evolution-3.1.4-1.fc16.x86_64
---> Package libsocialweb-keys.noarch 0:0.25.19-1.fc16 will be installed
--> Running transaction check
---> Package evolution-data-server.x86_64 0:3.1.4-1.fc16 will be updated
---> Package evolution-data-server.x86_64 0:3.1.5-2.fc16 will be an
update
--> Processing Dependency: libedataserver-1.2.so.15()(64bit) for
package: empathy-3.1.5.1-1.fc16.x86_64
--> Processing Dependency: libedataserver-1.2.so.15()(64bit) for
package: gnome-panel-3.1.5-2.fc16.x86_64
--> Processing Dependency: libedataserver-1.2.so.15()(64bit) for
package: 1:folks-0.6.0-5.fc16.x86_64
--> Processing Dependency: libedataserver-1.2.so.15()(64bit) for
package: gnome-shell-3.1.4-2.gite7b9933.fc16.x86_64
--> Processing Dependency: libecal-1.2.so.10()(64bit) for package:
gnome-panel-3.1.5-2.fc16.x86_64
--> Processing Dependency: libecal-1.2.so.10()(64bit) for package:
gnome-shell-3.1.4-2.gite7b9933.fc16.x86_64
--> Processing Dependency: libebook-1.2.so.12()(64bit) for package:
empathy-3.1.5.1-1.fc16.x86_64
--> Processing Dependency: libebook-1.2.so.12()(64bit) for package:
gnome-panel-3.1.5-2.fc16.x86_64
--> Processing Dependency: libebook-1.2.so.12()(64bit) for package:
1:folks-0.6.0-5.fc16.x86_64
--> Processing Dependency: libebook-1.2.so.12()(64bit) for package:
gnome-shell-3.1.4-2.gite7b9933.fc16.x86_64
--> Running transaction check
---> Package empathy.x86_64 0:3.1.4-1.fc16 will be updated
--> Processing Dependency: libgck.so.0()(64bit) for package:
empathy-3.1.4-1.fc16.x86_64
--> Processing Dependency: libgcr-3.so.1()(64bit) for package:
empathy-3.1.4-1.fc16.x86_64
---> Package empathy.x86_64 0:3.1.5.1-1.fc16 will be an update
---> Package evolution-data-server.x86_64 0:3.1.5-2.fc16 will be an
update
---> Package folks.x86_64 1:0.5.2-1.fc16 will be updated
---> Package folks.x86_64 1:0.6.0-5.fc16 will be an update
---> Package gnome-contacts.x86_64 0:0.1.2-2.fc16 will be an update
---> Package gnome-panel.x86_64 0:3.0.2-3.fc16 will be updated
--> Processing Dependency: gnome-panel-libs = 3.0.2-3.fc16 for package:
gnome-panel-3.0.2-3.fc16.x86_64
--> Processing Dependency: libgnome-menu.so.2()(64bit) for package:
gnome-panel-3.0.2-3.fc16.x86_64
---> Package gnome-panel.x86_64 0:3.1.5-2.fc16 will be an update
---> Package gnome-shell.x86_64 0:3.1.4-1.fc16 will be updated
--> Processing Dependency: libgnome-menu.so.2()(64bit) for package:
gnome-shell-3.1.4-1.fc16.x86_64
---> Package gnome-shell.x86_64 0:3.1.4-2.gite7b9933.fc16 will be an
update
---> Package libsocialweb.x86_64 0:0.25.19-1.fc16 will be installed
---> Package libsocialweb-keys.noarch 0:0.25.19-1.fc16 will be installed
---> Package p11-kit.x86_64 0:0.4-1.fc16 will be installed
--> Processing Dependency: libp11-kit.so.0()(64bit) for package:
gnome-keyring-3.1.4-1.fc16.x86_64
--> Running transaction check
---> Package empathy.x86_64 0:3.1.4-1.fc16 will be updated
--> Processing Dependency: libgck.so.0()(64bit) for package:
empathy-3.1.4-1.fc16.x86_64
--> Processing Dependency: libgcr-3.so.1()(64bit) for package:
empathy-3.1.4-1.fc16.x86_64
---> Package gnome-panel.x86_64 0:3.0.2-3.fc16 will be updated
--> Processing Dependency: libgnome-menu.so.2()(64bit) for package:
gnome-panel-3.0.2-3.fc16.x86_64
---> Package gnome-panel-libs.i686 0:3.0.2-3.fc16 will be installed
--> Processing Dependency: libX11.so.6 for package:
gnome-panel-libs-3.0.2-3.fc16.i686
--> Processing Dependency: libgdk_pixbuf-2.0.so.0 for package:
gnome-panel-libs-3.0.2-3.fc16.i686
--> Processing Dependency: libcairo.so.2 for package:
gnome-panel-libs-3.0.2-3.fc16.i686
--> Processing Dependency: libcairo-gobject.so.2 for package:
gnome-panel-libs-3.0.2-3.fc16.i686
--> Processing Dependency: libpthread.so.0 for package:
gnome-panel-libs-3.0.2-3.fc16.i686
--> Processing Dependency: libfreetype.so.6 for package:
gnome-panel-libs-3.0.2-3.fc16.i686
--> Processing Dependency: libgmodule-2.0.so.0 for package:
gnome-panel-libs-3.0.2-3.fc16.i686
--> Processing Dependency: libm.so.6 for package:
gnome-panel-libs-3.0.2-3.fc16.i686
--> Processing Dependency: libXau.so.6 for package:
gnome-panel-libs-3.0.2-3.fc16.i686
--> Processing Dependency: libatk-1.0.so.0 for package:
gnome-panel-libs-3.0.2-3.fc16.i686
--> Processing Dependency: libfontconfig.so.1 for package:
gnome-panel-libs-3.0.2-3.fc16.i686
--> Processing Dependency: libpangoft2-1.0.so.0 for package:
gnome-panel-libs-3.0.2-3.fc16.i686
--> Processing Dependency: libgio-2.0.so.0 for package:
gnome-panel-libs-3.0.2-3.fc16.i686
--> Processing Dependency: libpng12.so.0 for package:
gnome-panel-libs-3.0.2-3.fc16.i686
--> Processing Dependency: librt.so.1 for package:
gnome-panel-libs-3.0.2-3.fc16.i686
--> Processing Dependency: libc.so.6(GLIBC_2.4) for package:
gnome-panel-libs-3.0.2-3.fc16.i686
--> Processing Dependency: libpangocairo-1.0.so.0 for package:
gnome-panel-libs-3.0.2-3.fc16.i686
--> Processing Dependency: libgobject-2.0.so.0 for package:
gnome-panel-libs-3.0.2-3.fc16.i686
--> Processing Dependency: libgthread-2.0.so.0 for package:
gnome-panel-libs-3.0.2-3.fc16.i686
--> Processing Dependency: libpango-1.0.so.0 for package:
gnome-panel-libs-3.0.2-3.fc16.i686
--> Processing Dependency: libgdk-3.so.0 for package:
gnome-panel-libs-3.0.2-3.fc16.i686
--> Processing Dependency: libgconf-2.so.4 for package:
gnome-panel-libs-3.0.2-3.fc16.i686
--> Processing Dependency: libgtk-3.so.0 for package:
gnome-panel-libs-3.0.2-3.fc16.i686
--> Processing Dependency: libglib-2.0.so.0 for package:
gnome-panel-libs-3.0.2-3.fc16.i686
---> Package gnome-panel-libs.x86_64 0:3.0.2-3.fc16 will be updated
---> Package gnome-panel-libs.x86_64 0:3.0.2-3.fc16 will be updated
---> Package gnome-shell.x86_64 0:3.1.4-1.fc16 will be updated
--> Processing Dependency: libgnome-menu.so.2()(64bit) for package:
gnome-shell-3.1.4-1.fc16.x86_64
---> Package p11-kit.x86_64 0:0.3-2.fc16 will be installed
--> Running transaction check
---> Package GConf2.i686 0:3.1.6-1.fc16 will be installed
--> Processing Dependency: libpolkit-gobject-1.so.0 for package:
GConf2-3.1.6-1.fc16.i686
--> Processing Dependency: libdbus-1.so.3 for package:
GConf2-3.1.6-1.fc16.i686
--> Processing Dependency: libxml2.so.2(LIBXML2_2.4.30) for package:
GConf2-3.1.6-1.fc16.i686
--> Processing Dependency: libldap-2.4.so.2 for package:
GConf2-3.1.6-1.fc16.i686
--> Processing Dependency: libxml2.so.2 for package:
GConf2-3.1.6-1.fc16.i686
--> Processing Dependency: liblber-2.4.so.2 for package:
GConf2-3.1.6-1.fc16.i686
--> Processing Dependency: libdbus-glib-1.so.2 for package:
GConf2-3.1.6-1.fc16.i686
---> Package atk.i686 0:2.1.5-1.fc16 will be installed
---> Package cairo.i686 0:1.10.2-4.fc16 will be installed
--> Processing Dependency: libpixman-1.so.0 for package:
cairo-1.10.2-4.fc16.i686
--> Processing Dependency: libXrender.so.1 for package:
cairo-1.10.2-4.fc16.i686
--> Processing Dependency: libz.so.1 for package:
cairo-1.10.2-4.fc16.i686
---> Package cairo-gobject.i686 0:1.10.2-4.fc16 will be installed
---> Package empathy.x86_64 0:3.1.4-1.fc16 will be updated
--> Processing Dependency: libgck.so.0()(64bit) for package:
empathy-3.1.4-1.fc16.x86_64
--> Processing Dependency: libgcr-3.so.1()(64bit) for package:
empathy-3.1.4-1.fc16.x86_64
---> Package fontconfig.i686 0:2.8.0-4.fc16 will be installed
--> Processing Dependency: libexpat.so.1 for package:
fontconfig-2.8.0-4.fc16.i686
---> Package freetype.i686 0:2.4.6-1.fc16 will be installed
---> Package gdk-pixbuf2.i686 0:2.23.5-1.fc16 will be installed
--> Processing Dependency: libjpeg.so.62 for package:
gdk-pixbuf2-2.23.5-1.fc16.i686
--> Processing Dependency: libjpeg.so.62(LIBJPEG_6.2) for package:
gdk-pixbuf2-2.23.5-1.fc16.i686
--> Processing Dependency: libtiff.so.3 for package:
gdk-pixbuf2-2.23.5-1.fc16.i686
--> Processing Dependency: libjasper.so.1 for package:
gdk-pixbuf2-2.23.5-1.fc16.i686
---> Package glib2.i686 0:2.29.16-1.fc16 will be installed
--> Processing Dependency: libffi.so.5 for package:
glib2-2.29.16-1.fc16.i686
--> Processing Dependency: libfam.so.0 for package:
glib2-2.29.16-1.fc16.i686
--> Processing Dependency: libselinux.so.1 for package:
glib2-2.29.16-1.fc16.i686
---> Package glibc.i686 0:2.14.90-4 will be installed
--> Processing Dependency: libfreebl3.so for package:
glibc-2.14.90-4.i686
--> Processing Dependency: libfreebl3.so(NSSRAWHASH_3.12.3) for package:
glibc-2.14.90-4.i686
---> Package gnome-panel.x86_64 0:3.0.2-3.fc16 will be updated
--> Processing Dependency: libgnome-menu.so.2()(64bit) for package:
gnome-panel-3.0.2-3.fc16.x86_64
---> Package gnome-shell.x86_64 0:3.1.4-1.fc16 will be updated
--> Processing Dependency: libgnome-menu.so.2()(64bit) for package:
gnome-shell-3.1.4-1.fc16.x86_64
---> Package gtk3.i686 0:3.1.12-1.fc16 will be installed
--> Processing Dependency: libXrandr.so.2 for package:
gtk3-3.1.12-1.fc16.i686
--> Processing Dependency: libgssapi_krb5.so.2 for package:
gtk3-3.1.12-1.fc16.i686
--> Processing Dependency: libXcursor.so.1 for package:
gtk3-3.1.12-1.fc16.i686
--> Processing Dependency: libXcomposite.so.1 for package:
gtk3-3.1.12-1.fc16.i686
--> Processing Dependency: libXdamage.so.1 for package:
gtk3-3.1.12-1.fc16.i686
--> Processing Dependency: libcolord.so.1 for package:
gtk3-3.1.12-1.fc16.i686
--> Processing Dependency: libXext.so.6 for package:
gtk3-3.1.12-1.fc16.i686
--> Processing Dependency: libk5crypto.so.3 for package:
gtk3-3.1.12-1.fc16.i686
--> Processing Dependency: libXi.so.6 for package:
gtk3-3.1.12-1.fc16.i686
--> Processing Dependency: libcups.so.2 for package:
gtk3-3.1.12-1.fc16.i686
--> Processing Dependency: libcom_err.so.2 for package:
gtk3-3.1.12-1.fc16.i686
--> Processing Dependency: libXfixes.so.3 for package:
gtk3-3.1.12-1.fc16.i686
--> Processing Dependency: libXinerama.so.1 for package:
gtk3-3.1.12-1.fc16.i686
--> Processing Dependency: libkrb5.so.3 for package:
gtk3-3.1.12-1.fc16.i686
---> Package libX11.i686 0:1.4.3-1.fc16 will be installed
--> Processing Dependency: libxcb.so.1 for package:
libX11-1.4.3-1.fc16.i686
--> Processing Dependency: libgcc_s.so.1 for package:
libX11-1.4.3-1.fc16.i686
--> Processing Dependency: libgcc_s.so.1(GCC_3.0) for package:
libX11-1.4.3-1.fc16.i686
--> Processing Dependency: libgcc_s.so.1(GCC_3.3.1) for package:
libX11-1.4.3-1.fc16.i686
---> Package libXau.i686 0:1.0.6-2.fc15 will be installed
---> Package libpng.i686 2:1.2.46-1.fc16 will be installed
---> Package pango.i686 0:1.29.3-2.fc16 will be installed
--> Processing Dependency: libXft.so.2 for package:
pango-1.29.3-2.fc16.i686
--> Processing Dependency: libthai.so.0(LIBTHAI_0.1) for package:
pango-1.29.3-2.fc16.i686
--> Processing Dependency: libthai.so.0 for package:
pango-1.29.3-2.fc16.i686
--> Running transaction check
---> Package colord.i686 0:0.1.10-1.fc16 will be installed
--> Processing Dependency: libsqlite3.so.0 for package:
colord-0.1.10-1.fc16.i686
--> Processing Dependency: libgudev-1.0.so.0 for package:
colord-0.1.10-1.fc16.i686
--> Processing Dependency: libsane.so.1 for package:
colord-0.1.10-1.fc16.i686
--> Processing Dependency: libusb-1.0.so.0 for package:
colord-0.1.10-1.fc16.i686
--> Processing Dependency: liblcms2.so.2 for package:
colord-0.1.10-1.fc16.i686
---> Package cups-libs.i686 1:1.5.0-1.fc16 will be installed
--> Processing Dependency: libgcrypt.so.11 for package:
1:cups-libs-1.5.0-1.fc16.i686
--> Processing Dependency: libgnutls.so.26(GNUTLS_1_4) for package:
1:cups-libs-1.5.0-1.fc16.i686
--> Processing Dependency: libgpg-error.so.0 for package:
1:cups-libs-1.5.0-1.fc16.i686
--> Processing Dependency: libgnutls.so.26 for package:
1:cups-libs-1.5.0-1.fc16.i686
--> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4) for package:
1:cups-libs-1.5.0-1.fc16.i686
--> Processing Dependency: libstdc++.so.6(CXXABI_1.3) for package:
1:cups-libs-1.5.0-1.fc16.i686
--> Processing Dependency: libstdc++.so.6 for package:
1:cups-libs-1.5.0-1.fc16.i686
--> Processing Dependency: libaudit.so.1 for package:
1:cups-libs-1.5.0-1.fc16.i686
---> Package dbus-glib.i686 0:0.92-2.fc15 will be installed
---> Package dbus-libs.i686 1:1.4.10-3.fc16 will be installed
---> Package empathy.x86_64 0:3.1.4-1.fc16 will be updated
--> Processing Dependency: libgck.so.0()(64bit) for package:
empathy-3.1.4-1.fc16.x86_64
--> Processing Dependency: libgcr-3.so.1()(64bit) for package:
empathy-3.1.4-1.fc16.x86_64
---> Package expat.i686 0:2.0.1-11.fc15 will be installed
---> Package gamin.i686 0:0.1.10-10.fc16 will be installed
---> Package gnome-panel.x86_64 0:3.0.2-3.fc16 will be updated
--> Processing Dependency: libgnome-menu.so.2()(64bit) for package:
gnome-panel-3.0.2-3.fc16.x86_64
---> Package gnome-shell.x86_64 0:3.1.4-1.fc16 will be updated
--> Processing Dependency: libgnome-menu.so.2()(64bit) for package:
gnome-shell-3.1.4-1.fc16.x86_64
---> Package jasper-libs.i686 0:1.900.1-17.fc15 will be installed
---> Package krb5-libs.i686 0:1.9.1-8.fc16 will be installed
--> Processing Dependency: libkeyutils.so.1(KEYUTILS_0.3) for package:
krb5-libs-1.9.1-8.fc16.i686
--> Processing Dependency: libkeyutils.so.1 for package:
krb5-libs-1.9.1-8.fc16.i686
---> Package libXcomposite.i686 0:0.4.3-2.fc15 will be installed
---> Package libXcursor.i686 0:1.1.11-3.fc15 will be installed
---> Package libXdamage.i686 0:1.1.3-2.fc15 will be installed
---> Package libXext.i686 0:1.2.0-2.fc15 will be installed
---> Package libXfixes.i686 0:5.0-1.fc16 will be installed
---> Package libXft.i686 0:2.2.0-2.fc15 will be installed
---> Package libXi.i686 0:1.4.3-2.fc16 will be installed
---> Package libXinerama.i686 0:1.1.1-2.fc15 will be installed
---> Package libXrandr.i686 0:1.3.1-2.fc15 will be installed
---> Package libXrender.i686 0:0.9.6-2.fc15 will be installed
---> Package libcom_err.i686 0:1.41.14-2.fc15 will be installed
---> Package libffi.i686 0:3.0.10-1.fc16 will be installed
---> Package libgcc.i686 0:4.6.1-7.fc16 will be installed
---> Package libjpeg-turbo.i686 0:1.1.1-1.fc16 will be installed
---> Package libselinux.i686 0:2.1.4-2.fc16 will be installed
---> Package libthai.i686 0:0.1.14-4.fc15 will be installed
---> Package libtiff.i686 0:3.9.5-1.fc16 will be installed
---> Package libxcb.i686 0:1.7-3.fc16 will be installed
---> Package libxml2.i686 0:2.7.8-6.fc16 will be installed
---> Package nss-softokn-freebl.i686 0:3.12.10-4.fc16 will be installed
---> Package openldap.i686 0:2.4.26-1.fc16.1 will be installed
--> Processing Dependency: libssl3.so(NSS_3.4) for package:
openldap-2.4.26-1.fc16.1.i686
--> Processing Dependency: libplds4.so for package:
openldap-2.4.26-1.fc16.1.i686
--> Processing Dependency: libnss3.so(NSS_3.10) for package:
openldap-2.4.26-1.fc16.1.i686
--> Processing Dependency: libssl3.so for package:
openldap-2.4.26-1.fc16.1.i686
--> Processing Dependency: libnss3.so(NSS_3.11.1) for package:
openldap-2.4.26-1.fc16.1.i686
--> Processing Dependency: libssl3.so(NSS_3.7.4) for package:
openldap-2.4.26-1.fc16.1.i686
--> Processing Dependency: libplc4.so for package:
openldap-2.4.26-1.fc16.1.i686
--> Processing Dependency: libnss3.so(NSS_3.8) for package:
openldap-2.4.26-1.fc16.1.i686
--> Processing Dependency: libnss3.so(NSS_3.3) for package:
openldap-2.4.26-1.fc16.1.i686
--> Processing Dependency: libnss3.so(NSS_3.12) for package:
openldap-2.4.26-1.fc16.1.i686
--> Processing Dependency: libnss3.so(NSS_3.2) for package:
openldap-2.4.26-1.fc16.1.i686
--> Processing Dependency: libnss3.so(NSS_3.9.3) for package:
openldap-2.4.26-1.fc16.1.i686
--> Processing Dependency: libssl3.so(NSS_3.2) for package:
openldap-2.4.26-1.fc16.1.i686
--> Processing Dependency: libnss3.so(NSS_3.6) for package:
openldap-2.4.26-1.fc16.1.i686
--> Processing Dependency: libnssutil3.so for package:
openldap-2.4.26-1.fc16.1.i686
--> Processing Dependency: libnss3.so(NSS_3.12.9) for package:
openldap-2.4.26-1.fc16.1.i686
--> Processing Dependency: libnss3.so(NSS_3.9.2) for package:
openldap-2.4.26-1.fc16.1.i686
--> Processing Dependency: libsasl2.so.2 for package:
openldap-2.4.26-1.fc16.1.i686
--> Processing Dependency: libnss3.so for package:
openldap-2.4.26-1.fc16.1.i686
--> Processing Dependency: libsmime3.so for package:
openldap-2.4.26-1.fc16.1.i686
--> Processing Dependency: libnspr4.so for package:
openldap-2.4.26-1.fc16.1.i686
--> Processing Dependency: libnss3.so(NSS_3.4) for package:
openldap-2.4.26-1.fc16.1.i686
--> Processing Dependency: libnss3.so(NSS_3.12.5) for package:
openldap-2.4.26-1.fc16.1.i686
---> Package pixman.i686 0:0.22.2-1.fc16 will be installed
---> Package polkit.i686 0:0.101-7.fc16 will be installed
---> Package zlib.i686 0:1.2.5-4.fc16 will be installed
--> Running transaction check
---> Package audit-libs.i686 0:2.1.3-1.fc16 will be installed
---> Package cyrus-sasl-lib.i686 0:2.1.23-25.fc16 will be installed
--> Processing Dependency: libdb-5.2.so for package:
cyrus-sasl-lib-2.1.23-25.fc16.i686
---> Package empathy.x86_64 0:3.1.4-1.fc16 will be updated
--> Processing Dependency: libgck.so.0()(64bit) for package:
empathy-3.1.4-1.fc16.x86_64
--> Processing Dependency: libgcr-3.so.1()(64bit) for package:
empathy-3.1.4-1.fc16.x86_64
---> Package gnome-panel.x86_64 0:3.0.2-3.fc16 will be updated
--> Processing Dependency: libgnome-menu.so.2()(64bit) for package:
gnome-panel-3.0.2-3.fc16.x86_64
---> Package gnome-shell.x86_64 0:3.1.4-1.fc16 will be updated
--> Processing Dependency: libgnome-menu.so.2()(64bit) for package:
gnome-shell-3.1.4-1.fc16.x86_64
---> Package gnutls.i686 0:2.12.7-2.fc16 will be installed
--> Processing Dependency: libtasn1.so.3 for package:
gnutls-2.12.7-2.fc16.i686
--> Processing Dependency: libtasn1.so.3(LIBTASN1_0_3) for package:
gnutls-2.12.7-2.fc16.i686
---> Package keyutils-libs.i686 0:1.5.2-1.fc16 will be installed
---> Package lcms2.i686 0:2.2-2.fc16 will be installed
---> Package libgcrypt.i686 0:1.5.0-2.fc16 will be installed
---> Package libgpg-error.i686 0:1.10-1.fc16 will be installed
---> Package libgudev1.i686 0:173-1.fc16 will be installed
--> Processing Dependency: libudev.so.0 for package:
libgudev1-173-1.fc16.i686
---> Package libstdc++.i686 0:4.6.1-7.fc16 will be installed
---> Package libusb1.i686 0:1.0.9-0.2.git212ca37c.fc16 will be installed
---> Package nspr.i686 0:4.8.8-4.fc16 will be installed
---> Package nss.i686 0:3.12.10-6.fc16 will be installed
--> Processing Dependency: nss-softokn(x86-32) >= 3.12.10 for package:
nss-3.12.10-6.fc16.i686
---> Package nss-util.i686 0:3.12.10-1.fc16 will be installed
---> Package sane-backends-libs.i686 0:1.0.22-3.fc16 will be installed
--> Processing Dependency: libusb-0.1.so.4 for package:
sane-backends-libs-1.0.22-3.fc16.i686
--> Processing Dependency: libgphoto2_port.so.0 for package:
sane-backends-libs-1.0.22-3.fc16.i686
--> Processing Dependency: libieee1284.so.3 for package:
sane-backends-libs-1.0.22-3.fc16.i686
--> Processing Dependency: libexif.so.12 for package:
sane-backends-libs-1.0.22-3.fc16.i686
--> Processing Dependency: libv4l1.so.0 for package:
sane-backends-libs-1.0.22-3.fc16.i686
--> Processing Dependency: libgphoto2.so.2 for package:
sane-backends-libs-1.0.22-3.fc16.i686
---> Package sqlite.i686 0:3.7.7.1-1.fc16 will be installed
--> Processing Dependency: libtinfo.so.5 for package:
sqlite-3.7.7.1-1.fc16.i686
--> Processing Dependency: libreadline.so.6 for package:
sqlite-3.7.7.1-1.fc16.i686
--> Processing Dependency: libncurses.so.5 for package:
sqlite-3.7.7.1-1.fc16.i686
--> Running transaction check
---> Package empathy.x86_64 0:3.1.4-1.fc16 will be updated
--> Processing Dependency: libgck.so.0()(64bit) for package:
empathy-3.1.4-1.fc16.x86_64
--> Processing Dependency: libgcr-3.so.1()(64bit) for package:
empathy-3.1.4-1.fc16.x86_64
---> Package gnome-panel.x86_64 0:3.0.2-3.fc16 will be updated
--> Processing Dependency: libgnome-menu.so.2()(64bit) for package:
gnome-panel-3.0.2-3.fc16.x86_64
---> Package gnome-shell.x86_64 0:3.1.4-1.fc16 will be updated
--> Processing Dependency: libgnome-menu.so.2()(64bit) for package:
gnome-shell-3.1.4-1.fc16.x86_64
---> Package libdb.i686 0:5.2.28-2.fc16 will be installed
---> Package libexif.i686 0:0.6.20-1.fc16 will be installed
---> Package libgphoto2.i686 0:2.4.11-1.fc16 will be installed
--> Processing Dependency: libltdl.so.7 for package:
libgphoto2-2.4.11-1.fc16.i686
--> Processing Dependency: libgd.so.2 for package:
libgphoto2-2.4.11-1.fc16.i686
---> Package libieee1284.i686 0:0.2.11-10.fc15 will be installed
---> Package libtasn1.i686 0:2.7-2.fc15 will be installed
---> Package libudev.i686 0:173-1.fc16 will be installed
---> Package libusb.i686 1:0.1.3-9.fc16 will be installed
---> Package libv4l.i686 0:0.8.5-1.fc16 will be installed
---> Package ncurses-libs.i686 0:5.9-2.20110716.fc16 will be installed
---> Package nss-softokn.i686 0:3.12.10-4.fc16 will be installed
---> Package readline.i686 0:6.2-2.fc16 will be installed
--> Running transaction check
---> Package empathy.x86_64 0:3.1.4-1.fc16 will be updated
--> Processing Dependency: libgck.so.0()(64bit) for package:
empathy-3.1.4-1.fc16.x86_64
--> Processing Dependency: libgcr-3.so.1()(64bit) for package:
empathy-3.1.4-1.fc16.x86_64
---> Package gd.i686 0:2.0.35-12.fc15 will be installed
--> Processing Dependency: libXpm.so.4 for package:
gd-2.0.35-12.fc15.i686
---> Package gnome-panel.x86_64 0:3.0.2-3.fc16 will be updated
--> Processing Dependency: libgnome-menu.so.2()(64bit) for package:
gnome-panel-3.0.2-3.fc16.x86_64
---> Package gnome-shell.x86_64 0:3.1.4-1.fc16 will be updated
--> Processing Dependency: libgnome-menu.so.2()(64bit) for package:
gnome-shell-3.1.4-1.fc16.x86_64
---> Package libtool-ltdl.i686 0:2.4-6.fc16 will be installed
--> Running transaction check
---> Package empathy.x86_64 0:3.1.4-1.fc16 will be updated
--> Processing Dependency: libgck.so.0()(64bit) for package:
empathy-3.1.4-1.fc16.x86_64
--> Processing Dependency: libgcr-3.so.1()(64bit) for package:
empathy-3.1.4-1.fc16.x86_64
---> Package gnome-panel.x86_64 0:3.0.2-3.fc16 will be updated
--> Processing Dependency: libgnome-menu.so.2()(64bit) for package:
gnome-panel-3.0.2-3.fc16.x86_64
---> Package gnome-shell.x86_64 0:3.1.4-1.fc16 will be updated
--> Processing Dependency: libgnome-menu.so.2()(64bit) for package:
gnome-shell-3.1.4-1.fc16.x86_64
---> Package libXpm.i686 0:3.5.8-3.fc15 will be installed
--> Running transaction check
---> Package empathy.x86_64 0:3.1.4-1.fc16 will be updated
---> Package gnome-keyring.x86_64 0:3.1.1-2.fc16 will be updated
---> Package gnome-keyring.x86_64 0:3.1.4-1.fc16 will be an update
--> Processing Dependency: gnome-keyring = 3.1.4-1.fc16 for package:
gnome-keyring-pam-3.1.4-1.fc16.x86_64
---> Package gnome-menus.x86_64 0:3.0.1-1.fc16 will be updated
---> Package gnome-menus.x86_64 0:3.1.5-2.fc16 will be an update
--> Processing Dependency: libgnome-menu-3.so.0()(64bit) for package:
1:control-center-3.1.5-3.fc16.x86_64
---> Package gnome-panel.x86_64 0:3.0.2-3.fc16 will be updated
---> Package gnome-shell.x86_64 0:3.1.4-1.fc16 will be updated
---> Package p11-kit.x86_64 0:0.3-2.fc16 will be installed
--> Running transaction check
---> Package control-center.x86_64 1:3.1.4-1.fc16 will be updated
--> Processing Dependency: control-center-filesystem = 1:3.1.4-1.fc16
for package: 1:control-center-3.1.4-1.fc16.x86_64
---> Package control-center.x86_64 1:3.1.5-3.fc16 will be an update
---> Package gnome-keyring.x86_64 0:3.1.4-1.fc16 will be an update
---> Package gnome-keyring-pam.x86_64 0:3.1.1-2.fc16 will be updated
---> Package gnome-keyring-pam.x86_64 0:3.1.4-1.fc16 will be an update
---> Package gnome-menus.x86_64 0:3.1.5-2.fc16 will be an update
--> Running transaction check
---> Package control-center.x86_64 1:3.1.4-1.fc16 will be updated
---> Package control-center-filesystem.x86_64 1:3.1.4-1.fc16 will be
updated
---> Package control-center-filesystem.x86_64 1:3.1.5-3.fc16 will be an
update
--> Running transaction check
---> Package GConf2.i686 0:3.1.6-1.fc16 will be installed
---> Package atk.i686 0:2.1.5-1.fc16 will be installed
---> Package audit-libs.i686 0:2.1.3-1.fc16 will be installed
---> Package cairo.i686 0:1.10.2-4.fc16 will be installed
---> Package cairo-gobject.i686 0:1.10.2-4.fc16 will be installed
---> Package colord.i686 0:0.1.10-1.fc16 will be installed
---> Package cups-libs.i686 1:1.5.0-1.fc16 will be installed
---> Package cyrus-sasl-lib.i686 0:2.1.23-25.fc16 will be installed
---> Package dbus-glib.i686 0:0.92-2.fc15 will be installed
---> Package dbus-libs.i686 1:1.4.10-3.fc16 will be installed
---> Package expat.i686 0:2.0.1-11.fc15 will be installed
---> Package fontconfig.i686 0:2.8.0-4.fc16 will be installed
---> Package freetype.i686 0:2.4.6-1.fc16 will be installed
---> Package gamin.i686 0:0.1.10-10.fc16 will be installed
---> Package gd.i686 0:2.0.35-12.fc15 will be installed
---> Package gdk-pixbuf2.i686 0:2.23.5-1.fc16 will be installed
---> Package glib2.i686 0:2.29.16-1.fc16 will be installed
---> Package glibc.i686 0:2.14.90-4 will be installed
---> Package gnome-panel-libs.i686 0:3.0.2-3.fc16 will be installed
---> Package gnome-panel-libs.x86_64 0:3.0.2-3.fc16 will be updated
---> Package gnome-panel-libs.x86_64 0:3.1.5-2.fc16 will be an update
---> Package gnome-session.x86_64 0:3.1.3-1.fc16 will be updated
---> Package gnome-session.x86_64 0:3.1.5-1.fc16 will be an update
---> Package gnome-session-xsession.x86_64 0:3.1.3-1.fc16 will be
updated
---> Package gnome-session-xsession.x86_64 0:3.1.5-1.fc16 will be an
update
---> Package gnutls.i686 0:2.12.7-2.fc16 will be installed
---> Package gtk3.i686 0:3.1.12-1.fc16 will be installed
---> Package jasper-libs.i686 0:1.900.1-17.fc15 will be installed
---> Package keyutils-libs.i686 0:1.5.2-1.fc16 will be installed
---> Package krb5-libs.i686 0:1.9.1-8.fc16 will be installed
---> Package lcms2.i686 0:2.2-2.fc16 will be installed
---> Package libX11.i686 0:1.4.3-1.fc16 will be installed
---> Package libXau.i686 0:1.0.6-2.fc15 will be installed
---> Package libXcomposite.i686 0:0.4.3-2.fc15 will be installed
---> Package libXcursor.i686 0:1.1.11-3.fc15 will be installed
---> Package libXdamage.i686 0:1.1.3-2.fc15 will be installed
---> Package libXext.i686 0:1.2.0-2.fc15 will be installed
---> Package libXfixes.i686 0:5.0-1.fc16 will be installed
---> Package libXft.i686 0:2.2.0-2.fc15 will be installed
---> Package libXi.i686 0:1.4.3-2.fc16 will be installed
---> Package libXinerama.i686 0:1.1.1-2.fc15 will be installed
---> Package libXpm.i686 0:3.5.8-3.fc15 will be installed
---> Package libXrandr.i686 0:1.3.1-2.fc15 will be installed
---> Package libXrender.i686 0:0.9.6-2.fc15 will be installed
---> Package libcom_err.i686 0:1.41.14-2.fc15 will be installed
---> Package libdb.i686 0:5.2.28-2.fc16 will be installed
---> Package libexif.i686 0:0.6.20-1.fc16 will be installed
---> Package libffi.i686 0:3.0.10-1.fc16 will be installed
---> Package libgcc.i686 0:4.6.1-7.fc16 will be installed
---> Package libgcrypt.i686 0:1.5.0-2.fc16 will be installed
---> Package libgpg-error.i686 0:1.10-1.fc16 will be installed
---> Package libgphoto2.i686 0:2.4.11-1.fc16 will be installed
---> Package libgudev1.i686 0:173-1.fc16 will be installed
---> Package libieee1284.i686 0:0.2.11-10.fc15 will be installed
---> Package libjpeg-turbo.i686 0:1.1.1-1.fc16 will be installed
---> Package libpng.i686 2:1.2.46-1.fc16 will be installed
---> Package libselinux.i686 0:2.1.4-2.fc16 will be installed
---> Package libstdc++.i686 0:4.6.1-7.fc16 will be installed
---> Package libtasn1.i686 0:2.7-2.fc15 will be installed
---> Package libthai.i686 0:0.1.14-4.fc15 will be installed
---> Package libtiff.i686 0:3.9.5-1.fc16 will be installed
---> Package libtool-ltdl.i686 0:2.4-6.fc16 will be installed
---> Package libudev.i686 0:173-1.fc16 will be installed
---> Package libusb.i686 1:0.1.3-9.fc16 will be installed
---> Package libusb1.i686 0:1.0.9-0.2.git212ca37c.fc16 will be installed
---> Package libv4l.i686 0:0.8.5-1.fc16 will be installed
---> Package libxcb.i686 0:1.7-3.fc16 will be installed
---> Package libxml2.i686 0:2.7.8-6.fc16 will be installed
---> Package ncurses-libs.i686 0:5.9-2.20110716.fc16 will be installed
---> Package nspr.i686 0:4.8.8-4.fc16 will be installed
---> Package nss.i686 0:3.12.10-6.fc16 will be installed
---> Package nss-softokn.i686 0:3.12.10-4.fc16 will be installed
---> Package nss-softokn-freebl.i686 0:3.12.10-4.fc16 will be installed
---> Package nss-util.i686 0:3.12.10-1.fc16 will be installed
---> Package openldap.i686 0:2.4.26-1.fc16.1 will be installed
---> Package pango.i686 0:1.29.3-2.fc16 will be installed
---> Package pixman.i686 0:0.22.2-1.fc16 will be installed
---> Package polkit.i686 0:0.101-7.fc16 will be installed
---> Package readline.i686 0:6.2-2.fc16 will be installed
---> Package sane-backends-libs.i686 0:1.0.22-3.fc16 will be installed
---> Package sqlite.i686 0:3.7.7.1-1.fc16 will be installed
---> Package zlib.i686 0:1.2.5-4.fc16 will be installed
--> Finished Dependency Resolution

Packages skipped because of dependency problems:
    1:control-center-3.1.5-3.fc16.x86_64 from updates-testing
    1:control-center-filesystem-3.1.5-3.fc16.x86_64 from updates-testing
    empathy-3.1.5.1-1.fc16.x86_64 from updates-testing
    evolution-data-server-3.1.5-2.fc16.x86_64 from updates-testing
    1:folks-0.6.0-5.fc16.x86_64 from updates-testing
    gnome-contacts-0.1.2-2.fc16.x86_64 from updates-testing
    gnome-keyring-3.1.4-1.fc16.x86_64 from updates-testing
    gnome-keyring-pam-3.1.4-1.fc16.x86_64 from updates-testing
    gnome-menus-3.1.5-2.fc16.x86_64 from updates-testing
    gnome-panel-3.1.5-2.fc16.x86_64 from updates-testing
    gnome-shell-3.1.4-2.gite7b9933.fc16.x86_64 from updates-testing
    libsocialweb-0.25.19-1.fc16.x86_64 from fedora
    libsocialweb-keys-0.25.19-1.fc16.noarch from fedora
    p11-kit-0.3-2.fc16.x86_64 from fedora
    p11-kit-0.4-1.fc16.x86_64 from updates-testing
Error: Protected multilib versions:
gnome-panel-libs-3.1.5-2.fc16.x86_64 !=
gnome-panel-libs-3.0.2-3.fc16.i686

This is on a clean install of F16 alpha.
Jurgen

[Matthias Clasen]

On Wed, 2011-08-24 at 11:35 +0200, Jurgen Kramer wrote:
>  I have not seen any mention of this on the list so far so here it
> goes.
>  I've been seeing gnome dep problems for the last few days (through alpha
>  rc's and now alpha). 
>  Error: Protected multilib versions:
>  gnome-panel-libs-3.1.5-2.fc16.x86_64 !=
>  gnome-panel-libs-3.0.2-3.fc16.i686
>   
I have no idea what these errors mean or how to fix them.
Any advice would be appreciated. Actually, this one is kind of
understandable, but I have also seen 'protected multilib' stuff where
both sides of the != were the same arch, which left me wondering.

Matthias

[Clyde E. Kunkel]

On 08/24/2011 11:08 AM, Matthias Clasen wrote:
>  On Wed, 2011-08-24 at 11:35 +0200, Jurgen Kramer wrote:
> > I have not seen any mention of this on the list so far so here it goes.
> > I've been seeing gnome dep problems for the last few days (through alpha
> > rc's and now alpha).
>
> > Error: Protected multilib versions:
> > gnome-panel-libs-3.1.5-2.fc16.x86_64 !=
> > gnome-panel-libs-3.0.2-3.fc16.i686
> >
>
>  I have no idea what these errors mean or how to fix them.
>  Any advice would be appreciated. Actually, this one is kind of
>  understandable, but I have also seen 'protected multilib' stuff where
>  both sides of the != were the same arch, which left me wondering.
>
>  Matthias
>
>  
from https://admin.fedoraproject.org/updates/empathy-etc, etc, etc

"kiilerix - 2011-08-24 10:29:37 (karma 0)
              oldfart: the multilib error is a combination of yum
              bug 728147 and an unfortunate lack of arch in many
              dependencies"

-- 
Regards,
OldFart

[Richard Hughes]

On 24 August 2011 16:08, Matthias Clasen <mclasen(a)redhat.com&gt; wrote:
> > Error: Protected multilib versions:
> > gnome-panel-libs-3.1.5-2.fc16.x86_64 !=
> > gnome-panel-libs-3.0.2-3.fc16.i686
>  I have no idea what these errors mean or how to fix them. 
I'm seriously wondering if multilib is worth all this hassle...

Richard

[Tom Horsley]

On Wed, 24 Aug 2011 17:26:44 +0100
Richard Hughes wrote:

>  I'm seriously wondering if multilib is worth all this hassle...
Oh I've never wondered that: It has clearly never been a good
idea. Starting with the total lack of documentation about how
the heck it actually works when (for instance) multilib rpms
both contain /usr/bin binaries of the same name and going
through all the problems it causes with updates (like these).

Seems to me the "problem" should always have been fixed
by simply packaging the rpms correctly with shared noarch
bits in one rpm, /lib bits in another, /lib64 bits in
another, and /bin bits in yet another.

[Seth Vidal]

On Wed, 2011-08-24 at 13:09 -0400, Tom Horsley wrote:
>  On Wed, 24 Aug 2011 17:26:44 +0100
>  Richard Hughes wrote:
>  
>  > I'm seriously wondering if multilib is worth all this hassle...
>  
>  Oh I've never wondered that: It has clearly never been a good
>  idea. Starting with the total lack of documentation about how
>  the heck it actually works when (for instance) multilib rpms
>  both contain /usr/bin binaries of the same name and going
>  through all the problems it causes with updates (like these). 
It is documented it is just confusing

When you have two pkgs sharing the same binary path - the pkg in the
preferred/compat arch for that platform has its files installed.

Except when you install them in the wrong order - and then rpm will 
cough out a conflict. This, I think, has been fixed in more recent
changes but I'm not 100% certain of that.


>  
>  Seems to me the "problem" should always have been fixed
>  by simply packaging the rpms correctly with shared noarch
>  bits in one rpm, /lib bits in another, /lib64 bits in
>  another, and /bin bits in yet another. 
that doesn't fix the problem, though.;
-sv

[Panu Matilainen]

On 08/24/2011 08:11 PM, seth vidal wrote:
>  On Wed, 2011-08-24 at 13:09 -0400, Tom Horsley wrote:
> > On Wed, 24 Aug 2011 17:26:44 +0100
> > Richard Hughes wrote:
> >
> >> I'm seriously wondering if multilib is worth all this hassle...
> >
> > Oh I've never wondered that: It has clearly never been a good
> > idea. Starting with the total lack of documentation about how
> > the heck it actually works when (for instance) multilib rpms
> > both contain /usr/bin binaries of the same name and going
> > through all the problems it causes with updates (like these).
>
>  It is documented it is just confusing
>
>  When you have two pkgs sharing the same binary path - the pkg in the
>  preferred/compat arch for that platform has its files installed.
>
>  Except when you install them in the wrong order - and then rpm will
>  cough out a conflict. This, I think, has been fixed in more recent
>  changes but I'm not 100% certain of that. 
The conflict behavior should be consistent regardless of the order since 
rpm >= 4.6.0, ie since F10.

	- Panu -

[Bill Nottingham]

Matthias Clasen (mclasen(a)redhat.com) said: 
>  On Wed, 2011-08-24 at 11:35 +0200, Jurgen Kramer wrote:
>  > I have not seen any mention of this on the list so far so here it goes.
>  > I've been seeing gnome dep problems for the last few days (through alpha
>  > rc's and now alpha).
>  
>  > Error: Protected multilib versions:
>  > gnome-panel-libs-3.1.5-2.fc16.x86_64 !=
>  > gnome-panel-libs-3.0.2-3.fc16.i686
>  > 
>  
>  I have no idea what these errors mean or how to fix them.
>  Any advice would be appreciated. Actually, this one is kind of
>  understandable, but I have also seen 'protected multilib' stuff where
>  both sides of the != were the same arch, which left me wondering. 
That error is just a side-effect of how --skip-broken is working right
now. While that can be fixed, the real problem is that not everything
is rebuilt properly against the current versions of e-d-s and
libgnome-keyring.

Bill

[Adam Williamson]

On Wed, 2011-08-24 at 14:02 -0400, Bill Nottingham wrote:
>  Matthias Clasen (mclasen(a)redhat.com) said: 
>  > On Wed, 2011-08-24 at 11:35 +0200, Jurgen Kramer wrote:
>  > > I have not seen any mention of this on the list so far so here it goes.
>  > > I've been seeing gnome dep problems for the last few days (through alpha
>  > > rc's and now alpha).
>  > 
>  > > Error: Protected multilib versions:
>  > > gnome-panel-libs-3.1.5-2.fc16.x86_64 !=
>  > > gnome-panel-libs-3.0.2-3.fc16.i686
>  > > 
>  > 
>  > I have no idea what these errors mean or how to fix them.
>  > Any advice would be appreciated. Actually, this one is kind of
>  > understandable, but I have also seen 'protected multilib' stuff where
>  > both sides of the != were the same arch, which left me wondering.
>  
>  That error is just a side-effect of how --skip-broken is working right
>  now. While that can be fixed, the real problem is that not everything
>  is rebuilt properly against the current versions of e-d-s and
>  libgnome-keyring. 
Just about everything actually is, but it was done in fits and starts
and the Bodhi update edited over time, so not everything has made it to
every mirror yet. If you're particularly impatient you can set up a side
repo and stock it up from Koji to get the update done. That's what I
did.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Adam Williamson]

On Wed, 2011-08-24 at 12:01 -0700, Adam Williamson wrote:
>  On Wed, 2011-08-24 at 14:02 -0400, Bill Nottingham wrote:
>  > Matthias Clasen (mclasen(a)redhat.com) said: 
>  > > On Wed, 2011-08-24 at 11:35 +0200, Jurgen Kramer wrote:
>  > > > I have not seen any mention of this on the list so far so here it goes.
>  > > > I've been seeing gnome dep problems for the last few days (through
> alpha
>  > > > rc's and now alpha).
>  > > 
>  > > > Error: Protected multilib versions:
>  > > > gnome-panel-libs-3.1.5-2.fc16.x86_64 !=
>  > > > gnome-panel-libs-3.0.2-3.fc16.i686
>  > > > 
>  > > 
>  > > I have no idea what these errors mean or how to fix them.
>  > > Any advice would be appreciated. Actually, this one is kind of
>  > > understandable, but I have also seen 'protected multilib' stuff where
>  > > both sides of the != were the same arch, which left me wondering.
>  > 
>  > That error is just a side-effect of how --skip-broken is working right
>  > now. While that can be fixed, the real problem is that not everything
>  > is rebuilt properly against the current versions of e-d-s and
>  > libgnome-keyring.
>  
>  Just about everything actually is, but it was done in fits and starts
>  and the Bodhi update edited over time, so not everything has made it to
>  every mirror yet. If you're particularly impatient you can set up a side
>  repo and stock it up from Koji to get the update done. That's what I
>  did. 
It looks like the giganto-GNOME-update needs to be combined with the
e-d-s/dependencies update, too, as various bits of the giganto-GNOME
update are built against the newer e-d-s.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Matthias Clasen]

On Wed, 2011-08-24 at 12:08 -0700, Adam Williamson wrote:

>  > 
>  > Just about everything actually is, but it was done in fits and starts
>  > and the Bodhi update edited over time, so not everything has made it to
>  > every mirror yet. If you're particularly impatient you can set up a side
>  > repo and stock it up from Koji to get the update done. That's what I
>  > did.
>  
>  It looks like the giganto-GNOME-update needs to be combined with the
>  e-d-s/dependencies update, too, as various bits of the giganto-GNOME
>  update are built against the newer e-d-s. 
Everything in the gnome update has been built against the new eds. But I
somewhat disagree with the notion that we need to keep sucking up more
and more into this one update, making it ever harder to get any karma.

Can't people just wait until their mirrors sync and install the evo
update before they install the gnome update ? I mean, library deps still
work as they always did ?

[Adam Williamson]

On Wed, 2011-08-24 at 16:52 -0400, Matthias Clasen wrote:
>  On Wed, 2011-08-24 at 12:08 -0700, Adam Williamson wrote:
>  
>  > > 
>  > > Just about everything actually is, but it was done in fits and starts
>  > > and the Bodhi update edited over time, so not everything has made it to
>  > > every mirror yet. If you're particularly impatient you can set up a side
>  > > repo and stock it up from Koji to get the update done. That's what I
>  > > did.
>  > 
>  > It looks like the giganto-GNOME-update needs to be combined with the
>  > e-d-s/dependencies update, too, as various bits of the giganto-GNOME
>  > update are built against the newer e-d-s.
>  
>  Everything in the gnome update has been built against the new eds. But I
>  somewhat disagree with the notion that we need to keep sucking up more
>  and more into this one update, making it ever harder to get any karma.
>  
>  Can't people just wait until their mirrors sync and install the evo
>  update before they install the gnome update ? I mean, library deps still
>  work as they always did ? 
the problem is if either update gets karma and gets pushed before the
other, it puts the repo into a broken state. And since they're
inter-dependent, it causes confusion like people -1ing the gnome-shell
update because they don't have the packages from the e-d-s update; in a
way, having them separate is making it *harder* for you to get karma.

But yeah, I can see the problems with Enormo-Updates as well. I'm not
sure there's a really great way to handle updating such a giant mass of
inter-dependent packages, but if Luke or anyone else has any
suggestions...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Michael Cronenworth]

Adam Williamson wrote:
>  But yeah, I can see the problems with Enormo-Updates as well. I'm
> not
>  sure there's a really great way to handle updating such a giant mass of
>  inter-dependent packages, but if Luke or anyone else has any
>  suggestions... 
What's the problem with Enormo-Updates?

[Adam Williamson]

On Wed, 2011-08-24 at 16:43 -0500, Michael Cronenworth wrote:
>  Adam Williamson wrote:
>  > But yeah, I can see the problems with Enormo-Updates as well. I'm not
>  > sure there's a really great way to handle updating such a giant mass of
>  > inter-dependent packages, but if Luke or anyone else has any
>  > suggestions...
>  
>  What's the problem with Enormo-Updates? 
more or less, each package added to the update exponentially increases
the likelihood of false negative karma from someone whose local mirror
doesn't have one of the packages, or who hit a really tiny bug which
shouldn't be a case for a -1.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Michael Cronenworth]

Adam Williamson wrote:
>  more or less, each package added to the update exponentially
> increases
>  the likelihood of false negative karma from someone whose local mirror
>  doesn't have one of the packages, or who hit a really tiny bug which
>  shouldn't be a case for a -1. 
The first part sounds like a mirror problem that bodhi could never 
solve. If a mirror doesn't have all of the RPM files how could the yum 
repo data it provides possibly be valid? How could bodhi solve this? It 
can't.

The second part leaves me scratching my head. Minor dependencies should 
be just as important as large ones. If it is a dependency it needs to be 
linked and if it introduces bugs it should be important to fix them.

[Adam Williamson]

On Wed, 2011-08-24 at 17:21 -0500, Michael Cronenworth wrote:
>  Adam Williamson wrote:
>  > more or less, each package added to the update exponentially increases
>  > the likelihood of false negative karma from someone whose local mirror
>  > doesn't have one of the packages, or who hit a really tiny bug which
>  > shouldn't be a case for a -1.
>  
>  The first part sounds like a mirror problem that bodhi could never 
>  solve. If a mirror doesn't have all of the RPM files how could the yum 
>  repo data it provides possibly be valid? How could bodhi solve this? It 
>  can't. 
Weird stuff happens to mirrors. This is all I know. =)

>  The second part leaves me scratching my head. Minor dependencies
> should 
>  be just as important as large ones. If it is a dependency it needs to be 
>  linked and if it introduces bugs it should be important to fix them. 
I didn't say anything about dependencies. People file negative karma on
stuff like 'Obscure Menu Item Z doesn't work', or 'there's a typo in
the
docs'. The more packages there are in an update, the more likely this is
to happen, and the more likely bad negative karma will hold up 75 other
packages...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Michael Cronenworth]

Adam Williamson wrote:
>  I didn't say anything about dependencies. People file negative
> karma on
>  stuff like 'Obscure Menu Item Z doesn't work', or 'there's a typo in
> the
>  docs'. The more packages there are in an update, the more likely this is
>  to happen, and the more likely bad negative karma will hold up 75 other
>  packages... 
You kept mentioning adding more packages to updates causes problems. 
Typically adding packages is due to a dependency.

If you're not talking about dependencies, what are you talking about?

[Rahul Sundaram]

On 08/25/2011 04:06 AM, Michael Cronenworth wrote:
>  You kept mentioning adding more packages to updates causes problems. 
>  Typically adding packages is due to a dependency.
>
>  If you're not talking about dependencies, what are you talking about? 
Bodhi has the ability to bundle several updates together even when they
are not direct dependencies.  He is referring to that

Example:

https://admin.fedoraproject.org/updates/kde-l10n-4.6.5-1.fc14,kdeaccessib...

Rahul







]





Rahul

[Michael Cronenworth]

Rahul Sundaram wrote:
>  Bodhi has the ability to bundle several updates together even when
> they
>  are not direct dependencies.  He is referring to that 
Yes, I understand Bodhi can link any group of packages together.

>  Example:
>
>
> https://admin.fedoraproject.org/updates/kde-l10n-4.6.5-1.fc14,kdeaccessib...
So there are items in this list that could be shipped in a separate 
update without any negative side-effects? I'm not a KDE expert, but I 
don't see a package that could be left off.

If there are cases where package A and B are in an update and don't 
relate to each other and would run without crashing in separate updates 
then they should be in separate updates. I don't see that being the case 
in this thread unless I'm drinking cool-aid, which I very well might be 
doing.

[Rahul Sundaram]

 On 08/25/2011 04:23 AM, Michael Cronenworth wrote:

So there are items in this list that could be shipped in a separate
update without any negative side-effects? I'm not a KDE expert, but I
don't see a package that could be left off.

If there are cases where package A and B are in an update and don't
relate to each other and would run without crashing in separate updates
then they should be in separate updates. I don't see that being the case
in this thread unless I'm drinking cool-aid, which I very well might be
doing.

 Obviously noone would try to bundle completely unrelated packages in a
single update.     So I am not really what you are arguing about exactly.

Rahul

[Michael Cronenworth]

Rahul Sundaram wrote:
>  Obviously noone would try to bundle completely unrelated packages in
> a
>  single update.     So I am not really what you are arguing about exactly. 
Adam wanted to discuss "Enormo-Updates" and I think we just did.

*shrugs*

[Adam Williamson]

On Wed, 2011-08-24 at 17:53 -0500, Michael Cronenworth wrote:
>  Rahul Sundaram wrote:
>  > Bodhi has the ability to bundle several updates together even when they
>  > are not direct dependencies.  He is referring to that
>  
>  Yes, I understand Bodhi can link any group of packages together.
>  
>  >
>  > Example:
>  >
>  >
> https://admin.fedoraproject.org/updates/kde-l10n-4.6.5-1.fc14,kdeaccessib...
>  
>  So there are items in this list that could be shipped in a separate 
>  update without any negative side-effects? I'm not a KDE expert, but I 
>  don't see a package that could be left off.
>  
>  If there are cases where package A and B are in an update and don't 
>  relate to each other and would run without crashing in separate updates 
>  then they should be in separate updates. I don't see that being the case 
>  in this thread unless I'm drinking cool-aid, which I very well might be 
>  doing. 
No, you're not. By all policy, the GNOME update should be one
super-mega-giganto update, which it now is. We were just discussing the
reasons maintainers aren't very fond of those updates.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Adam Williamson]

On Wed, 2011-08-24 at 17:36 -0500, Michael Cronenworth wrote:
>  Adam Williamson wrote:
>  > I didn't say anything about dependencies. People file negative karma on
>  > stuff like 'Obscure Menu Item Z doesn't work', or 'there's a
> typo in the
>  > docs'. The more packages there are in an update, the more likely this is
>  > to happen, and the more likely bad negative karma will hold up 75 other
>  > packages...
>  
>  You kept mentioning adding more packages to updates causes problems. 
>  Typically adding packages is due to a dependency.
>  
>  If you're not talking about dependencies, what are you talking about? 
Um, exactly what you quoted. Larger updates tend to get more false
negative feedback. That's the main problem developers cite with them.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Tom Horsley]

On Wed, 24 Aug 2011 15:43:59 -0700
Adam Williamson wrote:

>  Um, exactly what you quoted. Larger updates tend to get more false
>  negative feedback. That's the main problem developers cite with them. 
Then it seems like the problem is the negative feedback, not
the size of the update. Maybe it should take more negative feedback
to stop a large update than a small one.

[Bruno Wolff III]

On Wed, Aug 24, 2011 at 18:48:48 -0400,
  Tom Horsley <horsley1953(a)gmail.com&gt; wrote:
>  On Wed, 24 Aug 2011 15:43:59 -0700
>  Adam Williamson wrote:
>  
>  > Um, exactly what you quoted. Larger updates tend to get more false
>  > negative feedback. That's the main problem developers cite with them.
>  
>  Then it seems like the problem is the negative feedback, not
>  the size of the update. Maybe it should take more negative feedback
>  to stop a large update than a small one. 
People are supposed to say why they are giving negative feedback, so that
the maintainer should be able to decide if the benefit of the fixes
going in out weigh the cost of any reported regressions.

[Matthias Clasen]

On Wed, 2011-08-24 at 14:39 -0700, Adam Williamson wrote:

>  the problem is if either update gets karma and gets pushed before
> the
>  other, it puts the repo into a broken state. And since they're
>  inter-dependent, it causes confusion like people -1ing the gnome-shell
>  update because they don't have the packages from the e-d-s update; in a
>  way, having them separate is making it *harder* for you to get karma. 
Ok, I've now merged all of the evo updates into the gnome update. Lets
see how that fares, dependency-wise.

[Adam Williamson]

On Wed, 2011-08-24 at 11:08 -0400, Matthias Clasen wrote:
>  On Wed, 2011-08-24 at 11:35 +0200, Jurgen Kramer wrote:
>  > I have not seen any mention of this on the list so far so here it goes.
>  > I've been seeing gnome dep problems for the last few days (through alpha
>  > rc's and now alpha).
>  
>  > Error: Protected multilib versions:
>  > gnome-panel-libs-3.1.5-2.fc16.x86_64 !=
>  > gnome-panel-libs-3.0.2-3.fc16.i686
>  > 
>  
>  I have no idea what these errors mean or how to fix them.
>  Any advice would be appreciated. Actually, this one is kind of
>  understandable, but I have also seen 'protected multilib' stuff where
>  both sides of the != were the same arch, which left me wondering. 
This particular one is just an odd artefact of --skip-broken trying to
workaround the dep problems from the *non* --skip-broken run. It
sometimes does some fairly odd things to try and work around the dep
issues. Usually it's not worth worrying about the oddness, in this case,
just focus on resolving the problems noted in the non --skip-broken run.
(Which just look like the Evo update didn't hit the reporter's mirror
yet).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Jonathan Corbet]

On Wed, 24 Aug 2011 11:08:52 -0400
Matthias Clasen <mclasen(a)redhat.com&gt; wrote:

>  > Error: Protected multilib versions:
>  > gnome-panel-libs-3.1.5-2.fc16.x86_64 !=
>  > gnome-panel-libs-3.0.2-3.fc16.i686
>  >   
>  
>  I have no idea what these errors mean or how to fix them.
>  Any advice would be appreciated. Actually, this one is kind of
>  understandable, but I have also seen 'protected multilib' stuff where
>  both sides of the != were the same arch, which left me wondering. 
I've worked my way through this kind of mess a couple of times now, most
recently yesterday.  Here's my experience:

 - Do a big rawhide update - in this case, at least two weeks worth.

 - Somewhere in the middle, while I'm not looking, the update kills the
   running session and/or X server - I come back to a login screen.  It
   used to be safe to run "yum update" from a terminal window, but,
   seemingly, not anymore.  Not really a step in the right direction. 

 - If I try to rerun the update, it will tell me to try
   yum-complete-transaction.  Each time, actually trying that leads to an
   infinite loop printing dependency information.

 - If I just run "yum update", I get the "protected multilib
versions"
   message.

What I have found in these cases is that there are *two* versions of the
indicated library installed simultaneously (for the same architecture).
In each case, simply removing the older version clears the problem.  Once
I've gotten past the gripes, the update actually works.

Dunno if that helps anybody...  never a dull moment...

jon

[Seth Vidal]

On Thu, 2011-08-25 at 11:12 -0600, Jonathan Corbet wrote:
>  On Wed, 24 Aug 2011 11:08:52 -0400
>  Matthias Clasen <mclasen(a)redhat.com&gt; wrote:
>  
>  > > Error: Protected multilib versions:
>  > > gnome-panel-libs-3.1.5-2.fc16.x86_64 !=
>  > > gnome-panel-libs-3.0.2-3.fc16.i686
>  > >   
>  > 
>  > I have no idea what these errors mean or how to fix them.
>  > Any advice would be appreciated. Actually, this one is kind of
>  > understandable, but I have also seen 'protected multilib' stuff where
>  > both sides of the != were the same arch, which left me wondering.
>  
>  I've worked my way through this kind of mess a couple of times now, most
>  recently yesterday.  Here's my experience:
>  
>   - Do a big rawhide update - in this case, at least two weeks worth.
>  
>   - Somewhere in the middle, while I'm not looking, the update kills the
>     running session and/or X server - I come back to a login screen.  It
>     used to be safe to run "yum update" from a terminal window, but,
>     seemingly, not anymore.  Not really a step in the right direction. 
>  
>   - If I try to rerun the update, it will tell me to try
>     yum-complete-transaction.  Each time, actually trying that leads to an
>     infinite loop printing dependency information.
>  
>   - If I just run "yum update", I get the "protected multilib
> versions"
>     message.
>  
>  What I have found in these cases is that there are *two* versions of the
>  indicated library installed simultaneously (for the same architecture).
>  In each case, simply removing the older version clears the problem.  Once
>  I've gotten past the gripes, the update actually works.
>  
>  Dunno if that helps anybody...  never a dull moment... 
When upgrading rawhide from X - use screen.

-sv

[Dave Jones]

On Thu, Aug 25, 2011 at 02:20:12PM -0400, seth vidal wrote:
 
>  > Dunno if that helps anybody...  never a dull moment...
>  
>  When upgrading rawhide from X - use screen. 
and also when upgrading from ssh.

things have definitely gotten a lot more fragile over the last
release or two.

	Dave

[Seth Vidal]

On Thu, 2011-08-25 at 14:28 -0400, Dave Jones wrote:
>  On Thu, Aug 25, 2011 at 02:20:12PM -0400, seth vidal wrote:
>   
>   > > Dunno if that helps anybody...  never a dull moment...
>   > 
>   > When upgrading rawhide from X - use screen.
>  
>  and also when upgrading from ssh.
>  
>  things have definitely gotten a lot more fragile over the last
>  release or two. 
you can disable the multilib protection with:

yum --setopt="protected_multilib=0" blah blah blah

which might help in situations where things are already deeply sideways.

-sv

[Adam Williamson]

On Thu, 2011-08-25 at 14:55 -0400, seth vidal wrote:
>  On Thu, 2011-08-25 at 14:28 -0400, Dave Jones wrote:
>  > On Thu, Aug 25, 2011 at 02:20:12PM -0400, seth vidal wrote:
>  >  
>  >  > > Dunno if that helps anybody...  never a dull moment...
>  >  > 
>  >  > When upgrading rawhide from X - use screen.
>  > 
>  > and also when upgrading from ssh.
>  > 
>  > things have definitely gotten a lot more fragile over the last
>  > release or two.
>  
>  you can disable the multilib protection with:
>  
>  yum --setopt="protected_multilib=0" blah blah blah
>  
>  which might help in situations where things are already deeply sideways. 
worth noting for the record that, as always when using 'force' type
parameters to a package management system, when it breaks - as it
inevitably will - you get a full refund of what you paid for it, and you
get to keep both pieces. =) generally, when yum wants to do something
really funky, the solution is not 'figure out how to let yum do it' but
'figure out why yum wants to do something funky, and fix that'.

(this is obviously not aimed at seth, who knows it already, but at the
thread in general.)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Seth Vidal]

On Thu, 2011-08-25 at 15:15 -0700, Adam Williamson wrote:
>  > 
>  > yum --setopt="protected_multilib=0" blah blah blah
>  > 
>  > which might help in situations where things are already deeply sideways.
>  
>  worth noting for the record that, as always when using 'force' type
>  parameters to a package management system, when it breaks - as it
>  inevitably will - you get a full refund of what you paid for it, and you
>  get to keep both pieces. =) generally, when yum wants to do something
>  really funky, the solution is not 'figure out how to let yum do it' but
>  'figure out why yum wants to do something funky, and fix that'.
>  
>  (this is obviously not aimed at seth, who knows it already, but at the
>  thread in general.) 

turning off them protected multilib option is not a 'force type' option.
All it does is allows yum to update one pkg w/o changing or matching the
the compat arch of the same pkg, too.

-sv

[Bill Nottingham]

Jonathan Corbet (corbet-ft(a)lwn.net) said: 
>   - Somewhere in the middle, while I'm not looking, the update
> kills the
>     running session and/or X server - I come back to a login screen.  It
>     used to be safe to run "yum update" from a terminal window, but,
>     seemingly, not anymore.  Not really a step in the right direction.  
There was a bug that caused dbus to get restarted when it should not
have been. I believe this is in the process of having a fix pushed.

Bill

[Adam Williamson]

On Thu, 2011-08-25 at 11:12 -0600, Jonathan Corbet wrote:
>  On Wed, 24 Aug 2011 11:08:52 -0400
>  Matthias Clasen <mclasen(a)redhat.com&gt; wrote:
>  
>  > > Error: Protected multilib versions:
>  > > gnome-panel-libs-3.1.5-2.fc16.x86_64 !=
>  > > gnome-panel-libs-3.0.2-3.fc16.i686
>  > >   
>  > 
>  > I have no idea what these errors mean or how to fix them.
>  > Any advice would be appreciated. Actually, this one is kind of
>  > understandable, but I have also seen 'protected multilib' stuff where
>  > both sides of the != were the same arch, which left me wondering.
>  
>  I've worked my way through this kind of mess a couple of times now, most
>  recently yesterday.  Here's my experience:
>  
>   - Do a big rawhide update - in this case, at least two weeks worth.
>  
>   - Somewhere in the middle, while I'm not looking, the update kills the
>     running session and/or X server - I come back to a login screen.  It
>     used to be safe to run "yum update" from a terminal window, but,
>     seemingly, not anymore.  Not really a step in the right direction.  
I don't think you could say it's ever been entirely *safe*; there's
always the potential that some update could do something to kill the
running session, and the more complex the definition of 'running
session', the more likely it is. Obviously a fat desktop on X is more
complex than a VT. I can only remember it happening to me once or twice,
but I'm not sure it's fair to say it's more likely now than in The
Golden Past.

I suspect the 'real fix' for that is to run your yum updates in a screen
session. I say 'suspect' because somehow I never quite get around to
learning how to use screen...but it seems like just the ticket, as it
would prevent the desktop going down from killing the yum update.

>  What I have found in these cases is that there are *two* versions of
> the
>  indicated library installed simultaneously (for the same architecture).
>  In each case, simply removing the older version clears the problem. 
What I'd actually recommend in that situation is doing 'rpm -e --justdb
--noscripts' on the 'old versions'; that will remove the entries from
RPM's database without possibly removing files that are actually part of
the newer one, or running scripts, which you don't want to happen.

In any case, that's not what's causing the 'protected multilib' thing
people are seeing in F16 now (or were yesterday), it's just an artefact
of yum trying to work around missing deps when you use --skip-broken.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

[Kalev Lember]

On 08/25/2011 08:12 PM, Jonathan Corbet wrote:
>  I've worked my way through this kind of mess a couple of times
> now, most
>  recently yesterday.  Here's my experience:
>  
>   - Do a big rawhide update - in this case, at least two weeks worth. 
A bit off topic, but I would personally encourage everybody to play with
the F16 tree instead of rawhide at this point.

When in the past rawhide was always what you'd get as the next upcoming
Fedora release, this is now slightly different. In the past, updates to
rawhide would slow down significantly when nearing a new release and the
repo would be frozen for weeks at a time. Now, however, rawhide is a
continuously flowing repo and releases are instead made of release branches.

Fedora 16 (also called 'Branched') was branched off of rawhide a month
ago. Since that time, most of the developers have switched from working
on rawhide to working on the F16 branch. What this means is that:

- rawhide gets much less love than usual during the F16 pre-Alpha -
  Final stages. Quite a lot of people want to get the new release
  polished up as good as possible and just don't pay much attention
  to rawhide bugs.

- The Branched tree might actually get new goodies earlier than
  rawhide, because this is what people are mostly concentrating on.

- Bug reports and general testing of the new Branched release is very
  valuable, and much more important than rawhide at this point.

What I personally do is that I switch to Branched when it gets branched
off of rawhide and stay on there until the release is out. After that,
back to the rawhide train. Everybody wins -- I get better experience,
newer goodies and a warm fuzzy feeling that I'm helping out with the new
release; the distro gets my help of making the release better.


-- 
Kalev

[Bruno Wolff III]

On Fri, Aug 26, 2011 at 10:28:37 +0300,
  Kalev Lember <kalevlember(a)gmail.com&gt; wrote:
>  When in the past rawhide was always what you'd get as the next
> upcoming
>  Fedora release, this is now slightly different. In the past, updates to
>  rawhide would slow down significantly when nearing a new release and the
>  repo would be frozen for weeks at a time. Now, however, rawhide is a
>  continuously flowing repo and releases are instead made of release branches. 
Depending on what one's testign goals are rawhide still may be a better
place to do testing. For example up until about a week ago, 3.1 kernels
were only being built for rawhide.

>  Fedora 16 (also called 'Branched') was branched off of
> rawhide a month
>  ago. Since that time, most of the developers have switched from working
>  on rawhide to working on the F16 branch. What this means is that:
>  
>  - rawhide gets much less love than usual during the F16 pre-Alpha -
>    Final stages. Quite a lot of people want to get the new release
>    polished up as good as possible and just don't pay much attention
>    to rawhide bugs. 
People should still be doing builds for F17 for things they have been doing
builds for in F16. Remember that while F17 inherits from F16, it doesn't
inherit from F16-updates-testing. (For example the updated gnome-shell
still isn't in the rawhode repo and needs to be grabbed separately for now.)

>  - The Branched tree might actually get new goodies earlier than
>    rawhide, because this is what people are mostly concentrating on. 
That works both ways, as I said about people are really supposed to be
doing builds for F17 at the same time. Normally this isn't a significant
amount of extra work.

>  - Bug reports and general testing of the new Branched release is
> very
>    valuable, and much more important than rawhide at this point. 
In general maybe, but not in all cases. This is probably more true once
we reach beta, where newer stuff in rawhide is less likely to be moved
to the branched release before final.

[Andre Robatino]

http://lists.fedoraproject.org/pipermail/devel/2011-August/155799.html

https://bugzilla.redhat.com/show_bug.cgi?id=731617

No progress in fixing it yet. Though I see roughly the same set of broken
dependencies in Rawhide, the problem does not exist there.

[Bruno Wolff III]

On Wed, Aug 24, 2011 at 16:59:22 +0000,
  Andre Robatino <robatino(a)fedoraproject.org&gt; wrote:
> http://lists.fedoraproject.org/pipermail/devel/2011-August/155799.html
>  
>  https://bugzilla.redhat.com/show_bug.cgi?id=731617
>  
>  No progress in fixing it yet. Though I see roughly the same set of broken
>  dependencies in Rawhide, the problem does not exist there. 
Rawhide is broken today (and has been for a few days now), with regard to
gnome-shell. You can grab the latest gnome-shell built for F16 and things
work.

[Andre Robatino]

Bruno Wolff III <bruno <at> wolff.to> writes:

>  Rawhide is broken today (and has been for a few days now), with
> regard to
>  gnome-shell. You can grab the latest gnome-shell built for F16 and things
>  work. 
I'm not sure what you mean by "broken" - for me, the original problem
(trying to
pull in 32-bit packages, and then failing due to conflicts) is gone now in F16
and never appeared in Rawhide. I'm using the master mirror
(download.fedora.redhat.com). Below are the packages I currently can't update in
Rawhide, and my gnome-shell version. Running "yum update --skip-broken" works
without excluding anything.

[root@localhost ~]# yum check-update
Loaded plugins: langpacks, presto, refresh-packagekit, security

ekiga.x86_64                                 3.3.1-3.fc17                rawhide
empathy.x86_64                               3.1.5.1-2.fc17              rawhide
evolution.x86_64                             3.1.5-1.fc17                rawhide
evolution-NetworkManager.x86_64              3.1.5-1.fc17                rawhide
evolution-data-server.x86_64                 3.1.5-1.fc17                rawhide
evolution-help.noarch                        3.1.5-1.fc17                rawhide
folks.x86_64                                 1:0.6.0-5.fc17              rawhide
gnome-contacts.x86_64                        0.1.2-2.fc17                rawhide
gnome-keyring.x86_64                         3.1.4-1.fc17                rawhide
gnome-keyring-pam.x86_64                     3.1.4-1.fc17                rawhide
gnome-menus.x86_64                           3.1.5-3.fc17                rawhide
gnome-panel.x86_64                           3.1.5-3.fc17                rawhide
gnome-panel-libs.x86_64                      3.1.5-3.fc17                rawhide
ptlib.x86_64                                 2.10.2-1.fc17               rawhide
[root@localhost ~]# rpm -q gnome-shell
gnome-shell-3.1.4-1.fc16.x86_64
[root@localhost ~]#

[Bruno Wolff III]

On Sat, Aug 27, 2011 at 19:31:31 +0000,
  Andre Robatino <robatino(a)fedoraproject.org&gt; wrote:
>  Bruno Wolff III <bruno <at> wolff.to> writes:
>  
>  I'm not sure what you mean by "broken" - for me, the original problem
> (trying to
>  pull in 32-bit packages, and then failing due to conflicts) is gone now in F16
>  and never appeared in Rawhide. I'm using the master mirror
>  (download.fedora.redhat.com). Below are the packages I currently can't update in
>  Rawhide, and my gnome-shell version. Running "yum update --skip-broken" works
>  without excluding anything. 
I was getting dependency errors trying to reinstall gnome-panel (which
brings in gnome-shell).

If you look at the problem report in today's rawhide report you will see
the folowwing:
	gnome-shell-3.1.4-1.fc16.x86_64 requires libgnome-menu.so.2()(64bit)
	gnome-shell-3.1.4-1.fc16.x86_64 requires libedataserver-1.2.so.14()(64bit)
	gnome-shell-3.1.4-1.fc16.x86_64 requires libecal-1.2.so.9()(64bit)
	gnome-shell-3.1.4-1.fc16.x86_64 requires libebook-1.2.so.11()(64bit)

[Andre Robatino]

Bruno Wolff III <bruno <at> wolff.to> writes:

>  I was getting dependency errors trying to reinstall gnome-panel
> (which
>  brings in gnome-shell). 
That problem, I DO have - gnome-panel-3.1.5-3.fc17.x86_64 is one of the packages
I couldn't install, and my current version is gnome-panel-3.0.2-3.fc16.x86_64
which I can't reinstall since it's not available from the repo (though it could
be gotten manually from Koji, I suppose).

[Bruno Wolff III]

On Sat, Aug 27, 2011 at 19:49:54 +0000,
  Andre Robatino <robatino(a)fedoraproject.org&gt; wrote:
>  Bruno Wolff III <bruno <at> wolff.to> writes:
>  
>  > I was getting dependency errors trying to reinstall gnome-panel (which
>  > brings in gnome-shell).
>  
>  That problem, I DO have - gnome-panel-3.1.5-3.fc17.x86_64 is one of the packages
>  I couldn't install, and my current version is gnome-panel-3.0.2-3.fc16.x86_64
>  which I can't reinstall since it's not available from the repo (though it could
>  be gotten manually from Koji, I suppose). 
I was able to install gnome-panel-3.1.5-3.fc17.i686 once I had
gnome-shell-3.1.4-2.gite7b9933.fc16.i686 in a local repo.