Built for me using gcc 4.0. Had to restart one time to make it work.  Same
problem as before.

My personal opinion on this, stable is just that, stable.  Stable-rc is frozen
except for bug fixes.  If we start integrating every version bump, it
degenerates back into test and we defeat the purpose of having the stable-rc
version.  My vote is for no, but I'd like to get swoolley's comment on this first.

Stable / stable-rc need to look at not just how stable that one individual spell
is, but how it affects everything else as well.

1.0.4 needs to go into stable because of security fixes, not because it's new
version.

oh, very well then, I say integrate

It's not a question of "if" it goes to stable but "when".  There's a 
very serious security fix and opening this bug is just to see if it 
works at all for enough people.  So I imagine he's looking for comments 
from people who have compiled it and tested it a bit.

:)

Arwed mentioned quite a few problems with this release. I just had the normal
problems for this update (had to start Firefox twice for it to work. Sometimes I
have to start it 3 to 5 times).

My guess about the multiple starts needed (which was the case here too, just a
little more complicated than just starting it twice) is that the
firefox-init.patch in the spell needs to be updated to the data in 1.0.4. I just
compared the data the patch puts into chrome.rdf with what my chrome.rdf really
contains now that firefox works and it's totally different.
If nobody else wants to do this I'll try updating it to work as intended for 1.0.4.

I'm working on this right now... 

I'm casting it without the patch right now too to generate a new one, let's see
if we come up with the same result :)

Created attachment 4254 [details]
patch for firefox spell

I tried to find another way to fix that without patching. I reused some lines
from BLFS ; using that spell, I didn't have any problem without running firefox
as root. search function is still working :)
Tested with flash and mplayerplug-in, no problem.
I also removed CVS options : there were broken last time I tested (and I don't
know if somebody really use that...)

Created attachment 4256 [details]
new firefox-init.patch

This is the new firefox-init.patch I created, with this it works fine for me.
I like your solution better though. Does it continue working if you start
firefox as root once? Does it work for multiple users?

With your spell firefox isn't completely setup after casting:
arwed@Otherland:~$ firefox
Extension System Warning: Failed to set up default extensions files probably
because you do not have write privileges to this location. While you can run
Firefox like this, it is recommended that you run it at least once with
privileges that allow it to generate these initial files to improve start
performance. Running from a disk image on MacOS X is not recommended.*** loading
the extensions datasource
*** ExtensionManager:_updateManifests: no access privileges to application
directory, skipping.

That's what the firefox-init.patch is supposed to solve (and does solve once
it's updated).

Created attachment 4259 [details]
firefox init for the "new" spell

Running firefox as root gives me this diff file on /usr/lib/firefox.Too bad, I
thought we could get rid of that init patch :(

I generated a diff myself, it has to be done by root with ~/.firefox and
~/.mozilla/firefox being empty, otherwise it didn't work for me.
Updated the patch in devel and test, works for me, please test.

>it has to be done by root with ~/.firefox and
>~/.mozilla/firefox being empty, otherwise it didn't work for me.

Not sure what you mean by that... Do we have to delete these directories first
otherwise it won't work ?

Only to generate the patch, not for anyone just using the spell.
The diff generated if /root/.firefox and /root/.mozilla/firefox exist is
different and doesn't work as intended.

OK. I tested : 
- first time patch didn't apply cleanly, and I had pb when relauching firefox. 
- second time (after removing /usr/lib/firefox and /root/.firefox), spell works fine
Are we sure that these files do not depend on the user settings (locales,
plugins, ...) ?

Since firefox (at least the spell built with the BLFS code) can work fine
without this patch, why not use this spell and add a warning like "you may want
to run firefox as root" ?

Because the spell should install everything needed for a package, IMO. And for
apps like firefox (user apps, not system administrator apps) we want it as easy
as possible. firefox currently annoys my g/f to no end when it's updated because
of the "problems" these firefox devs have (mozilla works just fine and doesn't
have these problems).

For the patch not applying, that used to happen to me when I tried updating the
patch for 1.0 (IIRC) and I had to rm -rf /lib/firefox and it worked fine.
Perhaps firefox isn't tracking the patch contents or we're doing some untracked
changes when we play with it. I'll try it on this machine and see.

Created attachment 4264 [details]
firefox init for the "new" spell (bis)

This one was created after removing files as Arwed advised

OK I understand the concerns. I'm only trying to promote the changes I made
because it's done without the mozconfig file (and without the `rm -f
/root/.mozconfig`). We can add an init patch on it, the good point is that it'll
be a lot smaller than the current one in test.

About cvs option, does it work and is it needed ?

The patched files are tracked correctly, the problem is that if the patch isn't
exactly correct running firefox as root will do more changes. And those changes
will lead to files left in /usr/lib/firefox on dispel.

Compiled and ran fine here on one machine (with Arwed's changes). Will test on
others now.

Thomas,
Your changes use mozconfig and remove /root/.mozconfig or your changes remove
those? Also, I'm not sure why your patch is bigger than Arwed's if you both
(presumably) did the same.

Most of the differences are in firefox/extensions/Extensions.rdf.

The changes don't use mozconfig, but only ./configure style. 
About the size of the patch, I think it's because with the changes, it runs
additional stuff in INSTALL.

Just trying to "cast -r -c firefox" (test grimoire) :-((

`dist/public/nss/swfortt.h' -> `/usr/include/firefox/nss/swfortt.h'
`dist/public/nss/watcomfx.h' -> `/usr/include/firefox/nss/watcomfx.h'
The next patch would create the file chrome/chrome.rdf,
which already exists!  Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file chrome/chrome.rdf.rej
The next patch would create the file
chrome/overlayinfo/browser/content/overlays.rdf,
which already exists!  Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file
chrome/overlayinfo/browser/content/overlays.rdf.rej
The next patch would create the file
chrome/overlayinfo/communicator/content/overlays.rdf,
which already exists!  Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file
chrome/overlayinfo/communicator/content/overlays.rdf.rej
The next patch would create the file
chrome/overlayinfo/inspector/content/overlays.rdf,
which already exists!  Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file
chrome/overlayinfo/inspector/content/overlays.rdf.rej
The next patch would create the file
chrome/overlayinfo/messenger/content/overlays.rdf,
which already exists!  Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file
chrome/overlayinfo/messenger/content/overlays.rdf.rej
The next patch would create the file
chrome/overlayinfo/navigator/content/overlays.rdf,
which already exists!  Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file
chrome/overlayinfo/navigator/content/overlays.rdf.rej
The next patch would create the file components/xpti.dat,
which already exists!  Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file components/xpti.dat.rej
The next patch would create the file components.ini,
which already exists!  Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file components.ini.rej
The next patch would create the file defaults.ini,
which already exists!  Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file defaults.ini.rej
The next patch would create the file
extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}/install.rdf,
which already exists!  Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file
extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}/install.rdf.rej
The next patch would create the file extensions/Extensions.rdf,
which already exists!  Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file extensions/Extensions.rdf.rej
The next patch would create the file extensions/installed-extensions-processed.txt,
which already exists!  Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file
extensions/installed-extensions-processed.txt.rej
Creating compile log /var/log/sorcery/compile/firefox-1.0.4.bz2
View Compile log for firefox-1.0.4? [n]
make: *** [firefox] Error 2

Spells that encountered problems:
---------------------------------
firefox

That's usually caused by an improperly tracked firefox install so that
prepare_install doesn't remove all of the old files. Can you try `dispel
firefox; rm -rf /usr/lib/firefox*; cast -c firefox`? May want to backup any
plugins in /usr/lib/firefox/plugins you want to keep.

Thanks Eric, now I remember I have had to run "rm -rf /usr/lib/firefox*" several
times before. :-)
Of course it works like a charm now.

IMHO, it could be optional part of INSTALL or at least it could be mentioned in
FINAL.

When I last played with the init patch for firefox I thought of having the rm
-rf, but then it'd remove plugins as well, which may not be wanted. A warning in
FINAL might be good, but I'd rather we get the spell so that it properly tracks
all the files so this work-around isn't sometimes needed. Some installs seem to
go fine, while others don't get tracked. I'm not sure why this happens. :(

With current firefox in devel, I cast and started it without any problems.
Previous version was 1.0.3 and it was dispelled.

How about only rm -f'ing the files the patch creates? That way it won't remove
any plugins but the patch should apply.

moving to stable grimoire :)

Arwed, I very like your solution.

I ran into trouble in stable-rc:

chmod +x revdepth
/usr/bin/perl -I. ./bdate.pl build_number 
rm -f nsBuildID.h
/usr/bin/perl -I. ./aboutime.pl -m ./milestone.txt nsBuildID.h build_number
./nsBuildID.h.in
gcc -DOSTYPE=\"Linux2.6.11\" -DOSARCH=\"Linux\"   -I../dist/include
-I../dist/include     -I/usr/X11R6/include   -fPIC -I/usr/X11R6/include -Wall -W
-Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -O -march=pentium4m
-mmmx -mfpmath=sse -msse -msse2 -pipe -O2 -pthread -pipe  -DNDEBUG -DTRIMMED
-ffunction-sections -O -march=pentium4m -mmmx -mfpmath=sse -msse -msse2 -pipe
-O2  -I/usr/X11R6/include -include ../mozilla-config.h -DMOZILLA_CLIENT 
-DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -I/usr/include/gtk-2.0
-I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0
-I/usr/include/pango-1.0 -I/usr/include/freetype2
-I/usr/include/freetype2/config -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include   -o elf-dynstr-gc elf-dynstr-gc.c -s   -lgtk-x11-2.0   
/usr/src/mozilla/config/nsinstall -R -m 644 nsBuildID.h ../mozilla-config.h
../dist/include
/usr/bin/perl -I../config ../config/build-list.pl ../dist/include/.headerlist
nsBuildID.h ../mozilla-config.h
rm -f ../config/final-link-comps ../config/final-link-libs
../config/final-link-comp-names
rm -f ../dist/bin/chrome/chromelist.txt
/usr/src/mozilla/config/nsinstall -t -m 644 nsBuildID.h ../mozilla-config.h
../dist/sdk/include
/usr/src/mozilla/config/nsinstall -R nsinstall ../dist/bin
/usr/src/mozilla/config/nsinstall -R -m 555 elf-dynstr-gc ../dist/bin
make[1]: Leaving directory `/usr/src/mozilla/config'
/usr/bin/make nspr
make[1]: Entering directory `/usr/src/mozilla'
/usr/bin/make -C nsprpub
make: *** nsprpub: No such file or directory.  Stop.
make: Entering an unknown directorymake: Leaving an unknown directorymake[1]:
*** [nspr] Error 2
make[1]: Leaving directory `/usr/src/mozilla'
make: *** [default] Error 2
 ! Problem Detected ! 
Creating compile log /var/log/sorcery/compile/firefox-1.0.4.bz2 
View Compile log for firefox-1.0.4? [n] 
make: *** [firefox] Error 2

Created attachment 4324 [details]
firefox-1.0.4.bz2

The full compile log

Ignore my last error message and compile log.  I wish I had run cleanse before
doing the update, but it's too late now.  I'm fairly sure that I had run cleanse
sometime since my last update, but I don't know for certain.

Anyways, running cleanse then retrying to cast firefox and it worked for me.  I
just wish I knew if another update caused breakage that caused firefox to break.

for me nss and nspr are cvs spells and I have abort on anything set on 
mine, so firefox always fails for one reason or another in my updates.

However, it worked for me in the new stable-rc when I skipped the abort.

I'm wondering what cleanse did to fix the problem though (I'd like 
upgrades to be smooth despite cleanse not being run, or else I have to 
note cleanse needing to be run in the release notes.

Working on the removal of the files the patch creates right now, will submit as
soon as the test cast finished.

Fixed in devel, test and stable-rc.

Integrated test/firefox/...@63408 (includes icon fix from Arjan) to
stable-rc/0.2 and stable/0.1. The other fixes were already in stable-rc/0.2 and
stable/0.1.

-- 

reassign to sm-grimoire-bugs