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
Karant
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:
http://scientificlinuxforum.org/index.php?act=ST&f=5&t=2634&st=0#e
ntry17238
Hi,
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
Matthieu.
Seemingly caused by:
https://bugzilla.redhat.com/show_bug.cgi?id=924414
This issue: https://bugzilla.redhat.com/show_bug.cgi?id=1061085
Thanks to everyone for the detailed information and the bug link!
Pat
Fix coming: https://bugzilla.redhat.com/show_bug.cgi?id=924414#c25
Akemi
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
auto-update?
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
--
Hi,
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.
Jon
$ 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
=============================================================================================================================================================
Updating:
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
-------------------------------------------------------------------------------------------------------------------------------------------------------------
Total
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
1/4
Updating : librsvg2-devel-2.26.0-6.el6_5.3.x86_64
2/4
Cleanup : librsvg2-devel-2.26.0-6.el6_5.2.x86_64
3/4
Cleanup : librsvg2-2.26.0-6.el6_5.2.x86_64
4/4
Updated:
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
Complete!
From:
http://ftp.scientificlinux.org/linux/scientific/6x/i386/updates/security/
[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)?
