Bug 244901 - Thunderbird 2.0.0.4 refuses to start
Thunderbird 2.0.0.4 refuses to start
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: thunderbird (Show other bugs)
7
All Linux
low Severity high
: ---
: ---
Assigned To: Gecko Maintainer
Fedora Extras Quality Assurance
: EasyFix
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-19 15:01 EDT by Markus Keppeler
Modified: 2008-02-29 08:54 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-29 08:54:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
specfile patch to explictly 'own' the mozappdir (416 bytes, patch)
2007-07-24 22:50 EDT, Kahlil Hodgson
no flags Details | Diff

  None (edit)
Description Markus Keppeler 2007-06-19 15:01:57 EDT
Description of problem: After the yum update to thunderbird 2.0.0.4-1.fc7
thunderbird refuses to start.

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

Solution: The directory /usr/lib/thunderbird-2.0.0.4 has wrong permissions
(700). Doing a "chown 755 /usr/lib/thunderbird-2.0.0.4" solved the problem.
Comment 1 Markus Keppeler 2007-06-19 15:03:52 EDT
I'm sorry. The solution is not
  chown 755 /usr/lib/thunderbird-2.0.0.4
but
  chmod 755 /usr/lib/thunderbird-2.0.0.4
Comment 2 Kahlil Hodgson 2007-07-21 23:33:54 EDT
(In reply to comment #0)
I just experienced the same problem during an upgrade from thunderbird-2.0.0.4
to thunderbird-2.0.0.5.
Comment 3 Kahlil Hodgson 2007-07-22 00:56:26 EDT
Just rebuilt the rpm from scratch.  Permissions are correct in the
RPM_BUILD_ROOT. Can't see any problems in the SPEC file.

If I completely remove thunderbird and reinstalling via yum. The permissions are
correct.  Hmm... note that /usr/lib/thunderbird-2.0.0.5 does not get removed
when I do an 'rpm -e'. I removed it manually so I could see what happens to perms.

This is reminds me of another bug where files under /usr/share/mime
loose their world access permissions. Maybe another package is screwing with the
perms.  Perhaps its something in the yum transaction.

The update set that triggered the issue for me this morning was as follows:

Jul 22 11:50:49 Updated: cairo.i386 1.4.10-1.fc7
Jul 22 11:50:49 Updated: gnome-python2-extras.i386 2.14.3-4.fc7
Jul 22 11:51:41 Installed: kernel.i686 2.6.22.1-27.fc7
Jul 22 11:51:42 Updated: gnome-python2-libegg.i386 2.14.3-4.fc7
Jul 22 11:51:42 Updated: mdadm.i386 2.6.2-4.fc7
Jul 22 11:51:43 Updated: livna-config-display.noarch 0.0.15-1.lvn7
Jul 22 11:51:54 Installed: kernel-devel.i686 2.6.22.1-27.fc7
Jul 22 11:51:58 Updated: thunderbird.i386 2.0.0.5-1.fc7
Jul 22 11:51:59 Updated: cairo-devel.i386 1.4.10-1.fc7
Jul 22 11:52:00 Installed: kmod-nvidia.i686 100.14.11-1.2.6.22.1_27.fc7
Jul 22 11:52:01 Updated: rpmdevtools.noarch 5.4-1.fc7
Jul 22 11:52:02 Updated: autofs.i386 5.0.1-20
Jul 22 11:52:02 Updated: gnome-python2-gtkhtml2.i386 2.14.3-4.fc7
Jul 22 11:52:04 Updated: kernel-headers.i386 2.6.22.1-27.fc7

I'll see if I can replicate this.

Comment 4 Markus Keppeler 2007-07-22 02:41:20 EDT
I had the same problem when i updated to 2.0.0.5. The following packages where
updated/installed:

Jul 21 15:02:25 Updated: cairo.i386 1.4.10-1.fc7
Jul 21 15:02:31 Updated: aqbanking.i386 2.3.2-1.fc7
Jul 21 15:02:32 Updated: qbanking.i386 2.3.2-1.fc7
Jul 21 15:02:41 Updated: gnucash-docs.noarch 2.2.0-1.fc7
Jul 21 15:02:41 Updated: gnome-python2-extras.i386 2.14.3-4.fc7
Jul 21 15:02:48 Installed: goffice04.i386 0.4.0-2.fc7
Jul 21 15:02:51 Installed: gtkhtml3.i386 3.14.3-1.fc7
Jul 21 15:03:16 Updated: gnucash.i386 2.2.0-1.fc7
Jul 21 15:03:18 Updated: libpaper.i386 1.1.21-1.fc7.1
Jul 21 15:04:36 Installed: kernel.i686 2.6.22.1-27.fc7
Jul 21 15:04:37 Updated: gnome-python2-libegg.i386 2.14.3-4.fc7
Jul 21 15:04:37 Updated: livna-config-display.noarch 0.0.15-1.lvn7
Jul 21 15:04:55 Installed: kernel-devel.i686 2.6.22.1-27.fc7
Jul 21 15:04:56 Installed: kmod-nvidia.i686 100.14.11-1.2.6.22.1_27.fc7
Jul 21 15:05:05 Updated: thunderbird.i386 2.0.0.5-1.fc7
Jul 21 15:05:07 Updated: autofs.i386 1:5.0.1-20
Jul 21 15:05:08 Updated: gnome-python2-gtkhtml2.i386 2.14.3-4.fc7
Jul 21 15:05:11 Updated: kernel-headers.i386 2.6.22.1-27.fc7

An observation: My /usr/lib/thunderbird-2.0.0.4 directory was not empty after
the update, because of german dictionaries in ./components/myspell. But i don't
think this can have anything to do with the problem.

When i reinstall thunderbird with

rpm -e thunderbird
rm -rf /usr/lib/thunderbird-2.0.0.5 (because of german dictionaries again)
yum -y install thunderbird

the problem does not occur.
Comment 5 Kahlil Hodgson 2007-07-22 03:50:29 EDT
I've isolated this as an issue with pup running via userhelper.
Will submit some notes after dinner:-)
Comment 6 Kahlil Hodgson 2007-07-22 05:23:27 EDT
Just created Bug 249180 under pirut which I believe may be the real cause of
this issue.  May also be something to do with PAM or consolehelper.
Comment 7 Kahlil Hodgson 2007-07-24 22:50:14 EDT
Created attachment 159900 [details]
specfile patch to explictly 'own' the mozappdir

Following the discussion under bug 249180, this patch appears to solve the 
problem.  Have tested using pup and a local repository.
Comment 8 Christopher Aillon 2007-08-07 13:05:09 EDT
Kahlil, thanks for the help debugging this.  does changing that line to read

%dir %{mozappdir}

fix the problem, too?  If not, then there's a file that's being pulled in that
we should explicitly list.  Can you provide a diff of the files listed by:

rpm -ql thunderbird

Before and after your patch?
Comment 9 Kahlil Hodgson 2007-08-07 22:07:12 EDT
Yeah,

%dir ${mozappdir}

also fixes the problem:-)

For me, it only occurs when using pup or system-install-packages and seems to
have something to do with me having set my (non-root) umask to 0007.

Ciao!
Comment 10 Christopher Aillon 2007-08-15 20:35:28 EDT
This is fixed in rawhide, btw.

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