Bug 177823 - thunderbird: icon not showing
thunderbird: icon not showing
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: thunderbird (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Christopher Aillon
: EasyFix, Regression
: 186166 186408 187291 (view as bug list)
Depends On:
Blocks: FC6Target
  Show dependency treegraph
 
Reported: 2006-01-14 18:13 EST by Andy Burns
Modified: 2008-05-13 05:39 EDT (History)
30 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-08 16:14:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
composed screen showing the 3x dodgy icons (86.29 KB, image/png)
2006-02-26 16:18 EST, David Timms
no flags Details
default.xpm (21.79 KB, image/png)
2006-03-29 11:55 EST, Michael Cronenworth
no flags Details
K menu with Thunderbird icon (6.98 KB, image/png)
2006-04-20 15:32 EDT, Dimitri Papadopoulos
no flags Details
task bar without Thunderbird icon (4.74 KB, image/png)
2006-04-20 15:34 EDT, Dimitri Papadopoulos
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Mozilla Foundation 284962 None None None Never

  None (edit)
Description Andy Burns 2006-01-14 18:13:06 EST
Description of problem:

Proper thunderbird icon is not shown on window frame task panel, just a generic
"square window with title bar" uicon instead, icon is ok on gnome applications menu.

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

rawhide 2006-01-14, has been like this for a few days for me

How reproducible:

100%

Steps to Reproduce:
1. run thunderbird 
  
Actual results:

naff icon

Expected results:

nice icon

Additional info:

running from email shortcut on panel, or gnome/apps/internet on menu, or as
/usr/bin/thunderbird from bash all give same result
Comment 1 Andy Burns 2006-01-23 16:29:26 EST
Fresh install from rawhide 2006-01-23, still no proper icon in gnome window list
applet, or thunderbird window itself, ok on gnome menu
Comment 2 Electron 2006-01-30 11:11:36 EST
Similar whith today release (Thunderbird 1.5 20060128) thunderbird-1.5-2
Comment 3 Andy Burns 2006-01-31 12:14:11 EST
Raising the priority as the lack of a quickly identifiable icon in the task list
does make it difficult to identify the "anonymous" thunderbird window while
multi-tasking.
Comment 4 Andrew Parker 2006-02-01 06:35:09 EST
Me too here post:

   I get the generic X app icon on KDE (FC5T2)
Comment 5 Jim Cornette 2006-02-01 23:45:15 EST
I am seeing the box without the ICON for both the alt-tab switching and with the
windows list.
Comment 6 Andy Burns 2006-02-04 15:06:10 EST
Thought I'd better investigate a few of the "obvious" potential reasons ...

$ sh -x thunderbird
+ MOZ_LIB_DIR=/usr/lib
+ '[' -x /usr/lib64/thunderbird-1.5/thunderbird-bin ']'
+ MOZ_LIB_DIR=/usr/lib64
+ MOZILLA_FIVE_HOME=/usr/lib64/thunderbird-1.5
+ MRE_HOME=/usr/lib64/thunderbird-1.5
+ export MOZILLA_FIVE_HOME MRE_HOME
+ MOZ_PROGRAM=/usr/lib64/thunderbird-1.5/thunderbird
+ MOZ_CLIENT_PROGRAM='/usr/lib64/thunderbird-1.5/thunderbird -remote'
+ MOZARGS=
++ check_running
++ /usr/lib64/thunderbird-1.5/thunderbird -remote 'ping()'
++ RETURN_VAL=2
++ '[' 2 -eq 2 ']'
++ echo 0
++ return 0
+ ALREADY_RUNNING=0
+ '[' -z '' ']'
+ '[' 0 -eq 1 ']'
+ rm_shit
+ find /home/andy/.thunderbird -name XUL.mfasl
+ xargs rm -f
+ exec /usr/lib64/thunderbird-1.5/thunderbird

$ cat /usr/share/applications/mozilla-thunderbird.desktop 
[Desktop Entry]
Version=1.0
Encoding=UTF-8
Name=Thunderbird Email
GenericName=Email
Comment=Send and Receive Email
Exec=thunderbird
Icon=thunderbird.png
Terminal=false
Type=Application
StartupWMClass=Thunderbird-bin
X-Desktop-File-Install-Version=0.10
Categories=Network;Application;X-Fedora;

$ locate thunderbird.png
/usr/share/icons/crystalsvg/16x16/apps/thunderbird.png
/usr/share/icons/crystalsvg/32x32/apps/thunderbird.png
/usr/share/pixmaps/thunderbird.png

]$ ls -l /usr/share/pixmaps/thunderbird.png
-rw-r--r-- 1 root root 21835 May 13  2005 /usr/share/pixmaps/thunderbird.png

$ file /usr/share/pixmaps/thunderbird.png
/usr/share/pixmaps/thunderbird.png: PNG image data, 152 x 152, 8-bit/color RGBA,
non-interlaced

$ gthumb /usr/share/pixmaps/thunderbird.png
<<looks good, proper mozilla thunderbird icon>>

$ cat /usr/share/applications/redhat-email.desktop
[Desktop Entry]
Name=Email
...
Comment=Send email and manage your schedule
...
Exec=launchmail
Icon=redhat-email.png
NoDisplay=true
Terminal=0
Type=Application
Encoding=UTF-8
Categories=X-Red-Hat-Base;X-Red-Hat-Base-Only;Network;Application;
StartupNotify=True

$ which launchmail
/usr/bin/launchmail

$ ls /usr/share/pixmaps/redhat-email.png
/usr/share/pixmaps/redhat-email.png

$ file /usr/share/pixmaps/redhat-email.png
/usr/share/pixmaps/redhat-email.png: symbolic link to
`../icons/Bluecurve/48x48/apps/redhat-email.png'

$ file /usr/share/pixmaps/../icons/Bluecurve/48x48/apps/redhat-email.png
/usr/share/pixmaps/../icons/Bluecurve/48x48/apps/redhat-email.png: symbolic link
to `icon-email.png'

$ ls -l /usr/share/icons/Bluecurve/48x48/apps/icon-email.png
-rw-r--r-- 1 root root 2642 Feb  1 20:17
/usr/share/icons/Bluecurve/48x48/apps/icon-email.png

$ file /usr/share/icons/Bluecurve/48x48/apps/icon-email.png
/usr/share/icons/Bluecurve/48x48/apps/icon-email.png: PNG image data, 48 x 48,
8-bit/color RGBA, non-interlaced

$ gthumb /usr/share/icons/Bluecurve/48x48/apps/icon-email.png
<<looks good, redhat envelope and stamp icon>>

/me scratches head ...
Comment 7 Jim Cornette 2006-02-05 23:09:52 EST
One strange thing I noticed about starting thunderbird, the ICON is in the
window list during initial loading of thunderbird. The ICON turns to default no
icon status shortly after the throbber release the icon.
Comment 8 David Timms 2006-02-26 09:08:41 EST
Hmm, still a problem with FC5T3 + pup-dates @ 2006-02-27.
Other app icons are normal.
Andy's analysis suggests he may be on 64 bit. I am seeing this with i386 install.
Comment 9 Christopher Aillon 2006-02-26 10:30:54 EST
This is actually intended by upstream -- the Thunderbird icon at small sizes
looks bad because it is so complex -- and they would rather distribute no icon
than a bad looking one.
Comment 10 Andy Burns 2006-02-26 15:47:21 EST
Seems an odd decision to me, on windows at least, the 16x16(?) thunderbird icon
looks equally as good as the firefox icon, the FX icon is instantly recognisable
on Linux at that size but thunderbird with this stock icon "submarines" out of
view :-(

Judging by the number of "me too" replies on this bug is it worth trying to
persuade upstream to change their behaviour, or is there a hidden
"display_generic_icon_below_x_pixels" pref?
Comment 11 David Timms 2006-02-26 16:18:49 EST
Created attachment 125286 [details]
composed screen showing the 3x dodgy icons

Just to ensure that we are talking about the same thing, see the 1000 words.

You'll notice that the task-selector bar @ 32x32 (i guess) also has the
problematic icon, when it needn't have it.

Two solutions: 
. use a 16x16 crafted icon rather than trying to scale a big one down; there is
nothing wrong with the one displayed in the gnome menu ? It's beautiful ;-)
. use at least a mail-like icon eg redhat/gnome (the one in the launcher
toolbar.) As also shown in the screen shot at 16x16, and looking dandy :)

Is the icon controlled by the window manager, or the app itself ? Is there a
requirement that image must be 32x32 and the wm scale it to the size it wants ?
Given the icon is not used anywhere else at 32x32, could we place a 16x16 icon
inside the file named for 32x32. Then scaling would not need to be performed
(except for the bigger one in the window list - rarely seen), leading to a
clearer image.

Going back 15 years to win3.1 days doesn't appeal to me in the least. I'd
rather not be using the OS considered the "laughing stock" ;)  [please take as
gentle jibe!]
Comment 12 David Chambers 2006-03-02 11:27:58 EST
At least on kde, it seems that you can restore the thunderbird icon in the
taskbar by copying mozilla/other-licenses/branding/thunderbird/default.xpm from
the source tree to /usr/lib/thunderbird-1.5/chrome/icons/default/  (you'll need
to make this directory first, as it does not exist by default).

Personally, I think the "thunderbird" icon thus produced is infinitely
preferable to the naff old "X" Icon seen previously.  I don't see why it's
supposed to look bad, to me it looks just as good as the firefox icon.

See also: https://bugzilla.mozilla.org/show_bug.cgi?id=284962 and
https://bugzilla.mozilla.org/show_bug.cgi?id=171349
Comment 13 Pierre Ossman 2006-03-03 05:08:41 EST
The argument that upstream wants this seems strange since the icon appears when
you run their nightly builds.
Comment 14 Remi Collet 2006-03-05 02:58:07 EST
I've modified the SPEC file to add (at the end of the install phase

# 177823
%{__mkdir_p} $RPM_BUILD_ROOT%{tbdir}/chrome/icons/default
%{__cp} other-licenses/branding/thunderbird/default.xpm \
	$RPM_BUILD_ROOT%{tbdir}/chrome/icons/default/	

And the icon is back for me. Firefox spec already contains the "nearly" same
commands :

%{__mkdir_p} $RPM_BUILD_ROOT%{ffdir}/chrome/icons/default/
%{__cp} %{SOURCE23} $RPM_BUILD_ROOT%{ffdir}/chrome/icons/default/default.xpm
%{__cp} %{SOURCE23} $RPM_BUILD_ROOT%{ffdir}/icons/default.xpm

Comment 15 Christopher Aillon 2006-03-23 13:10:49 EST
*** Bug 186166 has been marked as a duplicate of this bug. ***
Comment 16 Christopher Aillon 2006-03-23 13:11:10 EST
*** Bug 186408 has been marked as a duplicate of this bug. ***
Comment 17 Hugo Cisneiros 2006-03-23 22:09:52 EST
I'm using FC5 Final now and it gives me the generic X icon too.
Comment 18 Andy Burns 2006-03-27 10:48:04 EST
The numbner of "dupes" and "me too" continues to accumulate, I found a similar
long running entry in Mozilla's Bugzilla, and have cross-linked the two in the
hope that one of the other might get some attention ...

https://bugzilla.mozilla.org/show_bug.cgi?id=284962
Comment 19 Stephen Moore 2006-03-29 00:02:11 EST
Me too here post:

   I get the generic X app icon on GNOME FC5 release
Comment 20 Michael Cronenworth 2006-03-29 11:49:52 EST
I was getting a generic XFCE icon under XFCE 4.2.3.2 in FC5. I copied the file
mentioned in Comment #14 and that solved the problem. Can it can be patched via
the SPEC file for future releases?
Comment 21 Michael Cronenworth 2006-03-29 11:55:51 EST
Created attachment 127004 [details]
default.xpm

Place this file in the /usr/lib/thunderbird-1.5/chrome/icons/default directory
to get your icon back. Reload Thunderbird if it was already up. I'm attaching
this so everyone doesn't have to download the src RPM to get it.
Comment 22 Ian Pilcher 2006-03-29 18:03:52 EST
(In reply to comment #21)
> Place this file in the /usr/lib/thunderbird-1.5/chrome/icons/default directory
> to get your icon back. Reload Thunderbird if it was already up. I'm attaching
> this so everyone doesn't have to download the src RPM to get it.

Works for me.  Thanks.  (Note that the icons/default directory needs to be created.)
Comment 23 Johnny Proton 2006-04-05 10:49:19 EDT
So this is a Gnome, Redhat or Mozilla decision?  Judging by the some horrendous
icons included in FC5, I can't imagine it's something that Redhat did?

Look at Ekiga's icon and tell me if you can make any sense of that...
Comment 24 Dimitri Papadopoulos 2006-04-20 15:32:08 EDT
Created attachment 128059 [details]
K menu with Thunderbird icon

16 x 16 icon looks just fine
Comment 25 Dimitri Papadopoulos 2006-04-20 15:34:54 EDT
Created attachment 128060 [details]
task bar without Thunderbird icon

a 16 x 16 icon would still be better than X
Comment 26 Didier 2006-04-27 09:35:19 EDT
Probably redundant info :
Manually copying "/usr/lib/thunderbird-1.0.7/chrome/icons" (from FC4) to
"/usr/lib/thunderbird-1.5/chrome/icons" (FC5) yields all icons (composer,
address book, etc.).
Comment 27 Jan Houtsma 2006-04-30 16:29:30 EDT
Build your own rpm with the instructions described on
http://fedoranews.org/tchung/thunderbird/.

If you use the spec file mentioned there and rebuild the rpm with the latest tar
ball the icon is there again. I did so for TB 1.5.0.2 and it works.

You need to bump the version inside the spec file from 1.5 to 1.5.0.2 if you use
the 1.5.0.2 tar ball from mozilla the ftp because the example is for 1.5.
Comment 28 Michael Cronenworth 2006-05-03 10:18:15 EDT
Amazing... with the updated 1.5.0.2 RPM released yesturday this is still not
fixed. It's a simple SPEC file update guys...
Comment 29 Ian Pilcher 2006-05-06 10:56:02 EDT
(In reply to comment #28)
> Amazing... with the updated 1.5.0.2 RPM released yesturday this is still not
> fixed. It's a simple SPEC file update guys...

Additionally, the workaround in comment #21 no longer works for me.

Why are we deliberately making things uglier?
Comment 30 Ian Pilcher 2006-05-06 18:36:43 EDT
(In reply to comment #29)
> Additionally, the workaround in comment #21 no longer works for me.

OK, the workaround does work.  The icon file now needs to go in
/usr/lib/thunderbird-1.5.0.2/chrome/icons/default, which probably should have
been obvious.
Comment 31 Leon Flaks 2006-05-08 23:13:02 EDT
(In reply to comment #30)
>OK, the workaround does work.
The workaround did not work for me with version 1.5.0.2. I worked with 1.5 just
fine.
Comment 32 oll 2006-06-16 04:14:43 EDT
Unbelievable : still not corrected with 1.5.0.4 package.
Furthermore, the workaround doesn't work anymore !!
Comment 33 Matt Thompson 2006-06-16 11:16:39 EDT
oll:  The workaround works here.  I just moved the icons folder from
thunderbird-1.5.0.2/chrome to .4/chrome.
Comment 34 Scott Baker 2006-06-16 11:20:17 EDT
Can we get an official word from RedHat why this bug hasn't fixed since a work
around has been provided? Thunderbird is one of the very few apps that the icon
is broken on. Seems like a simple fix to me. 
Comment 35 David Chambers 2006-06-16 11:39:18 EDT
Indeed.  The spec file change needed is very minor, what's wrong with putting it in?

FWIW this is my addition to the end of the install phase in the spec file:-

%{__mkdir_p} $RPM_BUILD_ROOT%{tbdir}/chrome/icons/default
install -m644 dist/thunderbird/chrome/icons/default/* \
         $RPM_BUILD_ROOT%{tbdir}/chrome/icons/default/

- basically the same as Remi's change above.
Comment 36 Michael Cronenworth 2006-06-16 12:44:30 EDT
*sigh*

The Thunderbird 1.5.0.4 RPM was just released to updates today and this is still
not fixed.

Does anyone at RedHat read their bugs?

Hello? Anyone home? 6 months go buy for a 3 line SPEC FILE change.
Comment 37 Phil 2006-06-18 08:31:14 EDT
(In reply to comment #33)
> oll:  The workaround works here.  I just moved the icons folder from
> thunderbird-1.5.0.2/chrome to .4/chrome.

Doesn't work for me in FC5.
Comment 38 davidrobertwhite 2006-07-16 14:56:01 EDT
(In reply to comment #37)

> Doesn't work for me in FC5.

The workaround works for me in FC5.  I copied:

/usr/lib/thunderbird-1.5.0.4/icons/mozicon16.xpm

to

/usr/lib/thunderbird-1.5.0.4/chrome/icons/default/default.xpm

Then restarted Thunderbird.
Comment 39 Otto Rey 2006-07-28 12:05:52 EDT
Always the users are pushed to post bugs to improve, fix, etc, etc. But with
this STUPID bug and one that i post for gnome-screensaver i see that time to fix
really-simple bugs is extremely big. Why this bug is not fixed yet? How we cant
believe that posting bugs will help if these post are abandoned?

Whatever... FC5 with updates to 28-jul-2006 still have the same problem.
Comment 40 Rex Dieter 2006-07-31 10:58:16 EDT
AFAICT, it's this snippet in the specfile that's problematic (as it appears 
from cvs's 1.5.0.5-2 checkout today):

cd $RPM_BUILD_ROOT%{tbdir}/chrome
find . -name "*" -type d -maxdepth 1 -exec %{__rm} -rf {} \;
cd -

Not sure of the original rationale for omitting stuff under chrome/, but 
dropping this specfile code (and including chrome/ bits again) it makes things 
work properly.
Comment 41 Paul Smith 2006-08-09 06:07:42 EDT
Just to remember that this bug was not repaired in

Name        : thunderbird                  Relocations: (not relocatable)
Version     : 1.5.0.5                           Vendor: Red Hat, Inc.
Release     : 1.1.fc5                       Build Date: Tue 08 Aug 2006 09:27:18
PM WEST

Paul
Comment 42 Matthias Clasen 2006-08-15 14:06:33 EDT
Paul, tehre is no need to pile onto this bug whenever a new package is build...
Comment 43 Juliano F. Ravasi 2006-08-15 17:15:48 EDT
Sorry Matthias, but people will keep piling onto this bug until Fedora fixes it,
since it is so annoying and ugly at the same time it is so ridiculously simple
to fix (see comment #40 (also comment #14 and comment #35)).

There is a strange statement by Christopher Aillon on comment #9. If it means
that Mozilla itself removed the icon, this is absolutely not true. The icon is
shipped on Thunderbird packages from mozilla.org, and the icon is used on
application menus from both GNOME and KDE. It was one of his own changes that
caused the icon to disappear. I tracked it down on Fedora CVS and found the
specific commit:
http://cvs.fedora.redhat.com/viewcvs/devel/thunderbird/thunderbird.spec?r1=1.43&r2=1.44


There are pretty strong arguments on comment #3, comment #10, comment #11 and
comment #13; and two still unanswered questions on comment #23 and comment #34.
Comment 44 Matthias Clasen 2006-08-15 17:30:48 EDT
If the whining here becomes too annoying, we will have to close this bug.
Comment 45 Jim Richardson 2006-08-15 18:48:53 EDT
That arogant response was literally the straw that has broken this camel's back.
I have been a user and advocate of Redhat and Fedora systems for a number of
years. You can close this bug, you can delete my bugzilla account if you like.
Just know this, I installed kubuntu on my laptop this weekend. I believe FC5
will be the last Fedora desktop my computers will see.
Comment 46 Johnny Proton 2006-08-15 19:11:58 EDT
I agree with Jim.  That was no way to handle a public issue.

I love Fedora but I definitely don't see any "whining" at all going on here. 
Why can't Redhat explain what the reasoning is behind the bug so everyone at
least feels they aren't ignored?  It would be just as easy as the previous
comments by Matthias.
Comment 47 Hugo Cisneiros 2006-08-15 19:44:41 EDT
"Good" to see that some people always ignore simple issues concerned by their 
user base. After all, the user base's opinion is nothing right? Geez, close 
this bug, ignore the user and keep this "simple bug" to annoy every user that 
uses thunderbird.

I hate being a troll, but I watched this bug for months and I didn't want to 
ignore Mathias' comment this time. When we, users, do not report bugs and 
annoyances in the bugzilla, the distro asks us to do it. When we do it, we are 
being too annoying. Blah.
Comment 48 Pierre Ossman 2006-08-15 23:51:36 EDT
Seriously Matthias, what the hell? If this is the kind of attitude you're going
to have in regard to bugs that many find a big problem, then I really need to
reevaluate my choice in distribution. Both for my own use and in what I
recommend to customers.

Up until now I've considered Red Hat's handling of bugs to be very professional.
Get your act together and don't alianate a lot of people over a trivial issue
like this.
Comment 49 oll 2006-08-16 03:31:52 EDT
"whining"

I can't believe it !
Sucharrogance with people simply trying FREELY to help the Fedora Project.

Amazing !
Comment 50 Didier 2006-08-16 05:39:09 EDT
I have *never* been vocal about non-bug related comments in a Bugzilla report,
hating the whining as much as most every other, but I consider Matthias'
disappointing comment #44 unacceptable in the context of this bug's discussion ,
and a detriment to Fedora/Redhat's usual professionalism.

I fear my off-topic comment can be considered another candidate case in point to
close this bug report.
Comment 51 Chris Chabot 2006-08-16 08:41:50 EDT
(In reply to comment #44)
> If the whining here becomes too annoying, we will have to close this bug.

Maybe we should close your bugzilla account instead, fedora doesn't need your
help to ruin its reputation, nor do my contributions to fedora warrent an
@redhat.com to speak in such way to its users and fellow contributers.

Where's the public appology?
Comment 52 Matthias Clasen 2006-08-16 08:57:12 EDT
How about we all relax and remember that this is just about a missing icon, ok ?
There is plenty of crasher bugs to fix before a missing icon becomes a priority.
If some of the energy that is wasted here could be directed towards fixing some
of those, that would be nice.
Comment 53 Didier 2006-08-16 09:13:23 EDT
Granted there are more important bugs to fix. However, this bug :

1. has 100% end-user visibility (in contrast with some of the more obscure
crasher bugs);
2. seriously detriments end-user experience, as one cannot visually
differentiate between mail, compose, address book, ... windows ;
3. has a fix available (that is, there is no developer comment about the quality
of the aforementioned fix).

Your suggestion to limit ourselves to crasher bugs, allthough correct from a
certain point of view, suggests excluding myself - being no expert coder and not
having the inclination of becoming a Mozilla developer either - from further
contributing to a better Fedora experience by reporting bugs and/or suggesting
simple patches.

Ironically, I myself have - again by this off-topic (first time in 7 years of
RH/Fedora/Bugzilla use) comment - already invested more time than this bug
should warrant.

Comment 54 Max Spevack 2006-08-16 09:14:51 EDT
Matthias, if you'd just said comment #52 in comment #44, this thread would be in
much better shape.

But, if the fix is just a couple of lines in a spec file, I would hope we could
find a few minutes before FC6 to fix it.  There's low priority, and then there's
stuff that's so trivial there's no reason not to get there.

This bug feels more like the latter.

Set to block the FC6Target.
Comment 55 oll 2006-08-16 09:48:46 EDT
(In reply to comment #52)

> There is plenty of crasher bugs to fix before a missing icon becomes a priority.

Since 10 years I'm responsible from Linux worskstations, I rarely had so much
users complaining about one bug. All engineers here have a huge amount of
windows open in each workspace and since the mailer is their most used
application, it's really useful to switch to it easily.
Of course, it's technically near than nothing to solve it and there's far more
"serious" bugs, but an OS is like Circus : you applaud spectacular acts , far
more than the technically difficult ones.
Comment 56 Matthias Clasen 2006-08-16 15:27:47 EDT
Ok, since Max asked me nicely (hi Max !), I will apologize for the tone of 
comment #44. 

I do stand by the factual content though: too much bugzilla noise on pet bugs 
like this just lead to more important things getting lost in the noise. Every time
someone adds a "me too" or "still not fixed" comment here, this bug comes up in
our bug lists and steals a bit of concentration. If people want to have
free-ranging discussions ("threads" as Max put it), a mailing list is a much
better medium.
Comment 57 Greg DeKoenigsberg 2006-08-16 17:39:44 EDT
Matthias...

I know you've done a hell of a lot of work on Red Hat and Fedora's behalf.  I
know you're a great soldier.  But I'm sorry, I can't even support your assertion
of the correctness of the "factual content" of this as a "pet bug".

Did it ever occur to you that the "me too" syndrome in Bugzilla is actually a
*good thing*?  Even if it's a pain in your ass?  And for that matter, how many
"me too" bugs come with patches attached?

People don't bother to comment about bugs they don't care about.  They comment
about bugs that *hinder their ability to get things done*.  The metoo-ing of bug
reports may be one of our best barometers of the actual severity of a bug, in a
lot of ways.

Reading back through the history of this bug, we can see that:

1. The bug causes people serious pain, and has in fact been reported multiple
times (comments 3, 4, 5, 16, 18, 19 and notably 53);

2. The bug is trivially simple to fix -- or, if it isn't trivial, you've offered
*zero* explanation why it isn't (comments 28, 34, 35 and 36);

3. The assertion by caillon that this "bug" was in fact deliberate (comment 9)
followed by a number of eminently reasonable counter-arguments (comments 11, 12,
23, 24, and 25);

4. Numerous *actual proposed patches* have been submitted (comments 14, 35 and 40);

5. Your unwillingness even to acknowledge a patch, and your dismissal of
perfectly legitimate complaints as "whining," has *enraged* community members
(every comment after 44).

The most frustrating thing about this bug, and the reaction to it, is that has
all been so easily avoidable.  Honestly, how long would it have taken you to
incorporate (or at least comment on) the patch given to you in comment 40 by Rex
Dieter -- who, by the way, happens to be (a) the greatest champion of KDE in the
Fedora world, and (b) a member of the Fedora Board?

On the upside, I can't think of a better incentive for us to figure out how to
fix *ridiculous* problems like this one.  Sometimes public embarrassment is a
blessing.
Comment 58 Matthias Clasen 2006-08-16 18:03:02 EDT
I'm not in a position to acknowledge patches here. 

The package maintainer, who is also our closest Mozilla liaison, Chris Aillon,
has explained the reason for the current situation in comment #9 and I have no
reason to believe that he lied. So until Chris updates this bug with new
information about the situation, further comments here will not change the
situation.

Comment 59 Greg DeKoenigsberg 2006-08-16 18:43:05 EDT
Which is even more frustrating: you are speaking "authoritatively" about the bug
on the one hand, and then deferring the issue to Chris Aillon on the other hand.

Sigh.  Okay, I'll bite.

Chris, according to your comment 9: "This is actually intended by upstream --
the Thunderbird icon at small sizes looks bad because it is so complex -- and
they would rather distribute no icon than a bad looking one."

Which seems to be contradicted by comment 13 from Pierre Ossman: "The argument
that upstream wants this seems strange since the icon appears when you run their
nightly builds."

So one of the following is true:

1. The suggested patches fix the problem, we know they fix the problem, and
we're just too stubborn to put them in.  I'm pretty sure this isn't the case.  :)

2. The suggested patches do not fix the problem -- and we can't take the time to
explain why not.

3. We don't have time to verify the suggested patches and would rather leave
them alone until we do have time --and we can't take the time to explain why not.

At the *very* least, for this *particular* bug, it's time to explain the delay,
fix it if we can, defer it if we can't, and put the matter to rest.
Comment 60 Matthias Clasen 2006-08-16 19:02:27 EDT
I'll ask Chris when he's back from LinuxWorld
Comment 61 Johnny Proton 2006-08-17 00:08:46 EDT
This is good drama!

And this is also why Bugzilla is a very good thing.  Thanks to both of you for
making this a priority.
Comment 62 Chris Chabot 2006-08-17 01:12:34 EDT
(In reply to comment #40)
> AFAICT, it's this snippet in the specfile that's problematic (as it appears 
> from cvs's 1.5.0.5-2 checkout today):
> 
> cd $RPM_BUILD_ROOT%{tbdir}/chrome
> find . -name "*" -type d -maxdepth 1 -exec %{__rm} -rf {} \;
> cd -


This seems to be a pretty much straight copy from the firefox spec:
http://cvs.fedora.redhat.com/viewcvs/devel/firefox/firefox.spec?rev=HEAD&view=auto

However in the ff spec a few lines below it, it does:
%{__mkdir_p} $RPM_BUILD_ROOT%{ffdir}/chrome/icons/default/
%{__cp} %{SOURCE23} $RPM_BUILD_ROOT%{ffdir}/chrome/icons/default/default.xpm
%{__cp} %{SOURCE23} $RPM_BUILD_ROOT%{ffdir}/icons/default.xpm

which is missing from the thunderbird package (specificly the source23, which in
ff is the xpm icon, which is easily obtained from the tarbal)

Comment 63 Chris Chabot 2006-08-17 01:16:59 EDT
ps while digging in this i noticed 2 more differences from the ff spec:

FF has:
%ifarch ppc ppc64 s390 s390x
%define moz_make_flags -j1
%else
%define moz_make_flags %{?_smp_mflags}
%endif
MAKE="gmake %{moz_make_flags}" make -f client.mk build

however thunderbird only has:
make -f client.mk build_all

the missing -j flags do make the build quite a bit slower on my system :-)


Also it has a flag 'official_branding' and only when it is set to '1' 'should'
the build be 'official' (just guessing here :-)), however these 2 are not
conditional in the thunderbird spec file, and arn't in the ff spec:
export BUILD_OFFICIAL=1                                                         
export MOZILLA_OFFICIAL=1

Not sure if this is intended, but it would seem that these exports contradict
the conditional 'thunderbird-mozconfig-branded' configure flag:
--enable-official-branding

This bug probably isnt the right place for these observations, but i'm in a rush
to go to work :-)
Comment 64 Max Spevack 2006-09-05 13:52:01 EDT
so, it's been a couple of weeks and this bug is still a pretty trivial fix, and
it's still been completely ignored.  I assume Chris is back from LinuxWorld by
now.  Can we get an update please?
Comment 65 Christopher Aillon 2006-09-05 14:57:13 EDT
I'm waiting for an answer, but just re-pinged.  Will update the bug as soon as I
know more.

On an aside, it is very strangely interesting that this bug has gotten such a
"cult following" if you will.  This isn't even the default mailer in Fedora....
Does this imply that should change?  Interesting to think about....
Comment 66 Scott Baker 2006-09-05 16:07:49 EDT
This probably isn't the place to discuss what should or shouldn't be the default
mail application. Where should that discussion take place? Mailing list? Forum?
Where will the "right" people see it?

I would be in favor of replacing evolution though!
Comment 67 Christopher Aillon 2006-09-05 16:33:52 EDT
*Anywhere* but here.  I'd rather get flooded by everyone personally with mails
than discuss this here.  But hopefully there are more public fora that can be found.
Comment 68 Christopher Aillon 2006-09-06 14:40:26 EDT
So, I just got an okay to do this.  The concern was that the xpm didn't look
good against certain backgrounds and a few bugs were filed about it both in RH
bugzilla and in upstream bugzilla.  As I was trying to abide by the wishes
because of the trademark guidelines at the time (we were under review), I did
remove it.  Those bugs have since been fixed and it now appears other platforms
use this and scott says he thinks its now fine, so I'm going to go ahead and
re-add the icon in the next set of builds (which will be 1.5.0.5-7)
Comment 69 Max Spevack 2006-09-06 16:25:20 EDT
Fantastic, thanks very much for the update Chris.
Comment 70 Andy Burns 2006-09-07 02:10:49 EDT
Yay! I wish you'd provided a reference for your comment #9, it didn't seem to
stand up when at least the official win32 version does ship a 16x16 icon.

Thanks.
Comment 71 Andy Burns 2006-09-08 16:14:47 EDT
And lo! There *was* art for alt-tab :-)
Comment 72 Christopher Aillon 2006-09-15 16:36:35 EDT
*** Bug 187291 has been marked as a duplicate of this bug. ***
Comment 73 Mike Lann 2006-10-20 15:53:46 EDT
I had the exact same icon problem with version 1.5.0.7 (20060913) I downloaded
today for FC5.  It was corrected by creating the directories/files by copying:

/usr/lib/thunderbird-1.5.0.7/icons/mozicon16.xpm

to

/usr/lib/thunderbird-1.5.0.7/chrome/icons/default/default.xpm

I now have icons in the tray. Thank you to davidrobertwhite (Comment 38)

Comment 74 Paul Smith 2006-10-21 06:31:39 EDT
Should not the package of thunderbird do that automatically during its installation?

Paul
Comment 75 John Kuhns 2007-03-15 12:01:59 EDT
I had the same problem in 1.5.0.10 and again it was fixed by copying:

/usr/lib/thunderbird-1.5.0.10/icons/mozicon50.xpm

to 

/usr/lib/thunderbird-1.5.0.10/chrome/icons/default/default.xpm

mozicon50 gives a much sharper alt-tab-switching image than mozicon16

Note You need to log in before you can comment on or make changes to this bug.