On 02/05/2014 02:45 AM, Jon Clark wrote:
-----Original Message-----
From: owner-scientific-linux-us...@listserv.fnal.gov 
[mailto:owner-scientific-linux-us...@listserv.fnal.gov] On Behalf Of Yasha 
Sent: 05 February 2014 07:46
To: owner-scientific-linux-us...@listserv.fnal.gov
Cc: Mailling list for Scientific Linux users worldwide
Subject: Re: [SCIENTIFIC-LINUX-USERS] Nautilus respawning to infinity

On 02/04/2014 01:06 PM, Akemi Yagi wrote:
On Tue, Feb 4, 2014 at 6:08 AM, Pat Riehecky <riehe...@fnal.gov> wrote:
On 02/04/2014 07:24 AM, Elias Persson wrote:
On 2014-02-04 10:40, Matthieu Guionnet wrote:
Le 04/02/2014 04:52, John H. Outlan a écrit :
Several of us over at the forum are having a nautilus problem.
Nautilus is respawning non stop and filling the window list on
bottom panel.

Some with update, some with clean 6.5 x64 install.

Here's the forum link:

I confirm the reason and the (temporary)  solution.

It's due to the last librsvg2 update After a yum downgrade
librsvg2, Nautilus closes all the listed windows on bottom panel

Seemingly caused by:
This issue: https://bugzilla.redhat.com/show_bug.cgi?id=1061085
Thanks to everyone for the detailed information and the bug link!

Fix coming: https://bugzilla.redhat.com/show_bug.cgi?id=924414#c25

One small note.  I can confirm the defect -- I had just upgraded a colleague's 
IA-32 laptop workstation, and the entire desktop lost all icons (the user lives 
by icons and cannot effectively use a scrolling terminal without written key 
stroke instructions for each command, including return/enter keystrokes).  
However, I had installed both
librsvg2 and the -devel version, both of which automatically upgraded to the 
defective release.  I had to manually rpm -e of the -devel version before yum 
would allow the downgrade. After the downgrade, the window manager interface 
seems to be working.  I did attempt to use KDE instead of gnome (this being a 
login choice from a button on the login GUI screen), and KDE seemed to work for 
non-gnome applications, but I did
not extensively test the proper functioning of KDE.   As this "upgrade"
automatically was installed on many of our machines, we shall need to manually 
downgrade a number of machines.  Any ETA on the fixed version that should 

A separate question.  Unlike Microsoft, TUV EL is supposed to be a production 
enterprise system.  As this is a major failure of what amounts to a default GUI 
of EL, does anyone have an idea as to how this defect passed qualification 
testing prior to production release?  I am not expecting SL to test the 
functionality of TUV production release updates, but rather the correctness of 
the port from TUV to SL -- this defect clearly is a TUV issue.

Yasha Karant



I have just upgraded the librsvg2 package to the latest available version.  
This immediately solved the problem without the need for a manual rpm -e of the 
-devel version.  Details below.


$ sudo yum update librsvg2
Loaded plugins: presto, refresh-packagekit, security Setting up Update Process 
Resolving Dependencies
--> Running transaction check
---> Package librsvg2.x86_64 0:2.26.0-6.el6_5.2 will be updated
--> Processing Dependency: librsvg2 = 2.26.0-6.el6_5.2 for package:
--> librsvg2-devel-2.26.0-6.el6_5.2.x86_64
---> Package librsvg2.x86_64 0:2.26.0-6.el6_5.3 will be an update
--> Running transaction check
---> Package librsvg2-devel.x86_64 0:2.26.0-6.el6_5.2 will be updated
---> Package librsvg2-devel.x86_64 0:2.26.0-6.el6_5.3 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

  Package                                Arch                           Version 
                                    Repository                           Size
  librsvg2                               x86_64                         
2.26.0-6.el6_5.3                            sl-security                         
139 k
Updating for dependencies:
  librsvg2-devel                         x86_64                         
2.26.0-6.el6_5.3                            sl-security                         
 30 k

Transaction Summary
Upgrade       2 Package(s)

Total download size: 169 k
Is this ok [y/N]: y
Downloading Packages:
Setting up and reading Presto delta metadata Processing delta metadata
Package(s) data still to download: 169 k
(1/2): librsvg2-2.26.0-6.el6_5.3.x86_64.rpm                                     
                                                      | 139 kB     00:01
(2/2): librsvg2-devel-2.26.0-6.el6_5.3.x86_64.rpm                               
                                                      |  30 kB     00:00
                                              58 kB/s | 169 kB     00:02
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
   Updating   : librsvg2-2.26.0-6.el6_5.3.x86_64                                
   Updating   : librsvg2-devel-2.26.0-6.el6_5.3.x86_64                          
   Cleanup    : librsvg2-devel-2.26.0-6.el6_5.2.x86_64                          
   Cleanup    : librsvg2-2.26.0-6.el6_5.2.x86_64                                

   librsvg2.x86_64 0:2.26.0-6.el6_5.3

Dependency Updated:
   librsvg2-devel.x86_64 0:2.26.0-6.el6_5.3



[RPM] librsvg2-2.26.0-6.el6_5.3.i686.rpm <http://ftp.scientificlinux.org/linux/scientific/6x/i386/updates/security/librsvg2-2.26.0-6.el6_5.3.i686.rpm> 04-Feb-2014 15:40 139K

librsvg2-devel-2.26.0-6.el6_5.3.i686.rpm <http://ftp.scientificlinux.org/linux/scientific/6x/i386/updates/security/librsvg2-devel-2.26.0-6.el6_5.3.i686.rpm> 04-Feb-2014 15:40 30K

Thus, it appears that as of some time on 4 Feb, the later update was posted. Will any further updates using 6x (including "fresh" on-line updates to 6.5) now include this (presumably) functioning library? Is there a specific setting somewhere in the update mechanism (other than using the 6x repository) that is required to enable the latest (that is, skip 5.2 that still is listed and just use 5.3)?

Reply via email to