User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101230 Mandriva Linux/1.9.2.13-0.2mdv2010.2 (2010.2) Firefox/3.6.13 Build Identifier: Description of problem: script.js file missing in indexhtml page, which means the page doesn't redirect to www.mageia.org perhaps it would be possible to include the code directly on the page and also to revamp the default static page as well... Reproducible: Steps to Reproduce:
CC: (none) => dmorganecAssignee: ahmadsamir3891 => bugsquad
CC: (none) => thierry.vignaudComponent: Installation => RPM Packages
CC: (none) => mageia-webteamAssignee: bugsquad => rdalverny
Which page ?
CC: (none) => boklm
Maybe /usr/share/doc/HTML/index.html the default home page (in the alpha)
CC: (none) => manuel
default homepage from indexhtml package.
afaik the script.js still needs cleaning and isn't included? iirc rda was gonna fix it someday, so I filed this bug so it would be remembered.
The script is ok (rewritten and locally tested) and included in the package. But the spec file don't move it to the right place (and it does not rewrite one meta header at least).
Status: NEW => ASSIGNED
i wanted to take a look at it, but i didn't see any commit yet.
Priority: Normal => HighTarget Milestone: --- => Mageia 1
CC: thierry.vignaud => (none)
still not ok on mageia 1 alpha 2, i would like to help, but i still cannot see an update on svn... looking at the code, it seems that, we get directed to /usr/share/doc/HTML/index.html and not to /usr/share/mga/indexhtml/index.html (which does have images and script and everything)
Blocks: (none) => 56
indexhtml specfile puts everything correct under mga/indexhtml while doc/HTML has only one single HTML file; and that's the place where the browser is expected to go. See http://svnweb.mageia.org/packages/cauldron/firefox/current/SPECS/firefox.spec lines 295 and 301 where browser.startup.homepage property is set twice (duplicate) to doc/HTML/index.html Btw, using distribution-specific tag "mga" in the path is not good. So it involves a few other packages that depend on indexhtml (namely: evolution, midori, links, firefox). To fix this, I suggest: * update and cleanup indexhtml specfile so that: - we don't create/populate /usr/share/doc/HTML anymore - we move the home page in /usr/share/indexhtml/ - this is valid for welcome mail path too, we could move these in /usr/share/indexhtml/mail/ ? or /usr/share/welcomemail/ since we may move them into a separate package later? * so we will need to check dependent packages so that they use the correct path (however, only firefox and links seems to explicitly use the path in the spec file, so it may have been hardcoded somewhere else in other packages). * ensure it all works Cc'ing ennael for advice, who last committed on these packages (among others). I can do the indexhtml part and firefox/links specfile, but not sure about the rest (mail path, evolution, midori). What about Konqueror by the way?
CC: (none) => ennael1
(Doesn't block 56 as it's not an upgrade-related bug).
Blocks: 56 => (none)
or... you could base64 the script and image file and put it directly inside that single html file as a data blob.
I pushed a few changes (after ahmad's review) in the previous days that should fix that: * http://svnweb.mageia.org/soft?view=revision&revision=711 (indexhtml) * http://svnweb.mageia.org/packages?view=revision&revision=76932 (indexhtml) * http://svnweb.mageia.org/packages?view=revision&revision=76933 (firefox) * http://svnweb.mageia.org/packages?view=revision&revision=76936 (links) Not that indexhtml specfile is all clean now (there are hardcoded mga bits for the welcome mail), but it's another issue.
(In reply to comment #11) > I pushed a few changes (after ahmad's review) in the previous days that should > fix that: > * http://svnweb.mageia.org/soft?view=revision&revision=711 (indexhtml) > * http://svnweb.mageia.org/packages?view=revision&revision=76932 (indexhtml) > * http://svnweb.mageia.org/packages?view=revision&revision=76933 (firefox) > * http://svnweb.mageia.org/packages?view=revision&revision=76936 (links) > > Not that indexhtml specfile is all clean now (there are hardcoded mga bits for > the welcome mail), but it's another issue. I missed one bit, sorry. IINM, the %post section is redundant, as in Mageia indexhtml doesn't put any files in /usr/share/doc/HTML, I've removed it, (but won't submit until you review, you being the web/html guy and all :)).
(In reply to comment #12) > IINM, the %post section is redundant, as in Mageia indexhtml doesn't put any > files in /usr/share/doc/HTML, I've removed it, (but won't submit until you > review, you being the web/html guy and all :)). What's the diff exactly? :-p (index, /usr/share/doc/HTML is not here anymore, but there's a %post thing to do nonetheless).
Ah, yes, but then the comment is wrong. I'll add it back and remove the comment (and we'll have to use /tmp/tmpfile).
The logic is wrong in the spec: # add a default cat %buildroot/%_datadir/indexhtml/index.html | \ sed "s/#PRODUCT_ID//" | \ sed "s/#LANG/en/g" \ > tmpfile mv tmpfile %buildroot/%_datadir/indexhtml/index.html %post # done to prevent excludedocs to ignore the doc/HTML mkdir -p %_datadir/indexhtml sed -i "s/#PRODUCT_ID/`cat /etc/product.id`/" \ -i sed "s/#PRODUCT_ID/`cat /etc/product.id`/" \ -i sed sed "s/#LANG/${LC_NAME/[-_]*}/g" \ %_datadir/indexhtml/index.html in %post, %_datadir/indexhtml/index.html doesn't have #PRODUCT_ID or #LANG, they were already replaced in "add a default" in that same file.
Ah yes. So keeping only one is better. Can we keep only %post and remove the first one? or is there a case when %post may not be run on install?
This bug is fixed in indexhtml-1-3.mga1. Closing, reopen if the bug isn't fixed for you.
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED
still not working for me on my updated alpha 1 with FF. how to reproduce: - install alpha 1 - open FF and see that it doesn't work well, you see only "mageia" with a link. - update it completely - reboot - open firefox and and you see an error now: /usr/share/doc/HTML/index.html is not found. i suspect firefox home page needs to be corrected as well...
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
It won't work with old firefox profiles, as the: user_pref("browser.startup.homepage", "file:///usr/share/doc/HTML/index.html"); is already in ~/.mozilla/firefox/<profile name>/prefs.js. This is not the scope of this report. Also note that no rpm post scriptlet will/should ever touch a config file in the user's /home dir, and that whatever firefox default/system-wide default browser.startup.homepage is, it won't affect a setting in prefs.js, as prefs.js overrides system-wide settings... I guess a note could be dropped in the errata about this issue, with a sed command to fix it for the user, or explaining how to edit ~/.mozilla/firefox/<profile name>/prefs.js manually...
i will test on a new installation, if it's ok there, then i consider this closed as we should not "support" a non-stable release. I will check a little while later.
No need of a new installation, just rename ~/.mozilla or test in a new user account. I don't see where non-stable release enter here, this will affect any old firefox profile with any upgrade from an mdv release.
oh, ic that you are right. didn't think about upgrade from mdv... in that case, i would suggest keeping the /HTML/ directory, and perhaps linking the files in indexhtml/ to HTML/ ?
That looks like a good option. Ahmad, wdyt?
(In reply to comment #23) > That looks like a good option. Ahmad, wdyt? Then the symlink will have to be there for a very long time; the two options are: 1) the symlink is created and kept there for as long as 2010.x is supported (that somehow defines the reasons the files location were changes in indexhtml); Mageia ideally supports upgrading from 2010.x 2) no symlink is created and a note is dropped in the Errata, it's as simple as a single sed command on prefs.js in the user's profile, and is a one time issue.
(In reply to comment #24) My only concern here is for the upgrade path from 2010.x, so that users that didn't change their start page in the meantime do get the Mageia one: - so we should not change prefs.js anyway; - a symlink to be created only for Mageia 1 would be ok - later upgrades should not remove this symlink, right?
Another solution would be to set this in a shell wrapper when firefox is started ( ie, the sed stuff ). But this could change profile page when people do not want, so that's not ideal.
CC: (none) => misc
(In reply to comment #25) > (In reply to comment #24) > > My only concern here is for the upgrade path from 2010.x, so that users that > didn't change their start page in the meantime do get the Mageia one: > - so we should not change prefs.js anyway; > - a symlink to be created only for Mageia 1 would be ok - later upgrades > should not remove this symlink, right? The point is, if the user doesn't edit prefs.js to change the pref, it'll be there forever, people usually use the same profile as it contains bookmarks, tags, saved passwords... etc.
the symlinks looks like a big maintainability issue, but not having symlinks will probably create alot of noise, especially with reviewers who might "test" our upgrade path... so what if the few symlinks are there? is that a real problem? is it the end of the world if the user has it in his profile for 10years or more? not imho. what about other browsers?
(In reply to comment #27) > The point is, if the user doesn't edit prefs.js to change the pref, it'll be > there forever, people usually use the same profile as it contains bookmarks, > tags, saved passwords... etc. We can afford having their home page broken by a later release/upgrade - if they didn't customize it - when we would remove the symlink (we should perhaps leave a hint to this bug in the spec file?). Here the crucial thing is really the Mandriva 2010.x/Mageia 1 transition where we should not leave people in the void. (In reply to comment #28) > what about other browsers? Opera doesn't use this page afaik; links does and has been updated, however I don't know if there's a user prefs file for it.
(In reply to comment #29) > (In reply to comment #27) > > The point is, if the user doesn't edit prefs.js to change the pref, it'll be > > there forever, people usually use the same profile as it contains bookmarks, > > tags, saved passwords... etc. > > We can afford having their home page broken by a later release/upgrade - if > they didn't customize it - when we would remove the symlink (we should perhaps > leave a hint to this bug in the spec file?). > > Here the crucial thing is really the Mandriva 2010.x/Mageia 1 transition where > we should not leave people in the void. > I see your point, (so we break it for Mageia 2 :)). Symlink added and a new package submitted.
Status update? Or can we close this one?
Last time I tested, it worked as expected.
Ok, then; thanks.
Status: REOPENED => RESOLVEDResolution: (none) => FIXED
CC: boklm => (none)