Bug 99560

Summary: updating to gnome-panel 2.0.6-9.2 mangles default bottom panel
Product: [Retired] Red Hat Linux Reporter: Robert M. Riches Jr. <rmriches>
Component: gnome-panelAssignee: Havoc Pennington <hp>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-08-07 20:43:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Robert M. Riches Jr. 2003-07-21 20:26:16 UTC
Description of problem:
After updating (via up2date) gnome-panel from 2.0.6-9 to 2.0.6-9.2,
a gnome user logging in and starting X gets the message, "No panels
were found in your configuration.  I will create a menu panel for you."
The previous default bottom-edge panel is gone.  Instead, there is a
tiny, nearly empty panel at the top of the screen.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Have a gnome user blissfully using the default bottom panel
   under gnome-panel-2.0.6-9.
2. Update to gnome-panel-2.0.6-9.2
3. Gnome user log in and start X.
4. Observe the error message box and modified panel.
Actual results:
An error dialogue box appears.  The bottom panel is gone.  A
tiny, nearly empty top panel has been created.

Expected results:
A very minor version change should retain the existing default
bottom panel and its contents.

Additional info:

Comment 1 Robert M. Riches Jr. 2003-07-21 20:50:29 UTC
Correction: The problem happens on systems updated via manual
'rpm', not on systems updated via up2date.  The output of
'rpm -qa' is identical with respect to all Redhat-supplied
packaged on the two systems.  The output of 'rpm -V' on
gnome-panel is identical between the two systems.  Yet, the
two systems give different behavior when starting X for a
gnome session.

Comment 2 Robert M. Riches Jr. 2003-07-26 02:58:19 UTC
In case anyone's looking at this report, I found a workaround.
Using tar, I copied /etc/gconf from the good machine to the
bad machines (same set of installed RPMs, so they should have
been identical to start with).  Also, I had to restore all Gnome
users' $HOME/gconf{,d} directories from backups.  There was no
change to any 'rpm -V ...' result from the operation.

Why did 'up2date' and 'rpm -Uvh ...' produce different results
in /etc/gconf?  Why didn't 'rpm -V ...' show the difference?
Inquiring minds want to know.  :-)

Comment 3 Havoc Pennington 2003-08-07 20:43:29 UTC
The gconf files aren't rpm-managed so rpm -V won't do anything.

Maybe you somehow didn't run the %post for the RPM?

It's hard to know; I think at this point it's pretty unlikely 
we'll track this down and release a fix for 8.0, since we're almost done 
with the release after 9.

If I was going to debug it I'd probably have a look at the detailed difference
between the working and nonworking gconf files.

Comment 4 Robert M. Riches Jr. 2003-08-07 22:59:22 UTC
I'd be happy to send tarballs of bad and good gconf trees,
if that would be of any value.  It sounds like you wouldn't
want to do anything with them, so unless I hear otherwise
I'll refrain from sending them to save you some disk space.
If you'd like them, please say so and I'll be happy to send