SeaMonkey 1.0.8 upcoming, planning for 1.1.1
Robert Kaiser
http://wiki.mozilla.org/Firefox:1.5.0.10-2.0.0.2
We're planning to ship SeaMonkey 1.0.8 in parallel with Gecko 1.8.0.10
(Firefox 1.5.0.10), the first candidate builds are up here:
http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/candidates-1.0.8/
Windows and Linux builds are there already, I had to rebuild on Mac
because some tests failed (probably timeouts because the machine was
busy doing a second build at the same time).
We haven't dome a big number of changes there compared to 1.0.7, I think
SeaMonkey-specific code saw only 1 security fix, the rest is Core/Gecko
fixes.
We'd be happy to get smoketests on all platforms, please help us testing
this!
As for the future of 1.0.x, we've started thinking about maybe making
this the last fully official 1.0.x release. We will keep the source
updated with security fixes in CVS for a while, and may still do
source-only update releases, but we might stop putting up binaries and
needing to do QA on them, as our primary stable releases are now the
1.1.x series.
I'd be happy about feedback on such a strategy.
While talking about 1.1.x being the "primary stable releases" now, we're
also trying to get a SeaMonkey 1.1.1 ready for releasing.
This has seen a good flow of fixes since 1.1, and we'd like to get those
out to users, ideally, we'd make the date of Gecko 1.8.1.2, but maybe
we'll need a small bit more time for QA.
Currently, our bug radar queries are down to good numbers, with no
confirmed or requested release blockers, 0-1 approval requests, but a
handful of approved patches to still get checked in:
confirmed blockers:
https://bugzilla.mozilla.org/buglist.cgi?keywords_type=nowords&keywords=fixed-seamonkey1.1.1%2Cfixed1.8.1.2%2Cverified1.8.1.2&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=blocking-seamonkey1.1.1%2B
requested blockers:
https://bugzilla.mozilla.org/buglist.cgi?keywords_type=nowords&keywords=fixed-seamonkey1.1.1%2Cfixed1.8.1.2%2Cverified1.8.1.2&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=blocking-seamonkey1.1.1%3F
approval requests:
https://bugzilla.mozilla.org/request.cgi?type=approval-seamonkey1.1.1
approved, need checkin:
https://bugzilla.mozilla.org/buglist.cgi?keywords_type=nowords&keywords=fixed-seamonkey1.1.1%2Cfixed1.8.1.2%2Cverified1.8.1.2&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=approval-seamonkey1.1.1%2B
Until we're ready to put up cadidate builds, please help us testing the
current 1.8 branch nightlies:
http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-mozilla1.8/
I hope we can get both security update releases in shape and out the
door soon.
Thanks for your help,
Robert Kaiser
SeaMonkey Council member
Benoit Renard
We're not even close to six months after 1.1, and unless 1.1.1 or 1.1.2
fixes everything that has gone bad 1.0.7 -> 1.1, this is bad news for
mailnews users. I wouldn't do it out of principle.
Phillip M. Jones, C.E.T
Hello Robert.
Have you seen my Bug on Suntrust Bill Page section not drawing correctly
on SM but fine on FF 2.0.
And The bug with Save-As not working correctly when using Command-S.
You need to fix those before bring out the SM 1.1.1 updates.
They are very aggravating bugs to me.
The second bug is not at all in SM1.0.7 and one responder says its a
broken Widget problem in the base code for FF2/SM1.1.
THe first has shown up after Suntrust completely redesigned the Bill Pay
section. And I can confirm that its only a problem in SM not FF. both on
OSX.3.9, OSX4.8.
--
------------------------------------------------------------------------
Phillip M. Jones, CET http://www.vpea.org
If it's "fixed", don't "break it"! mailto:pjo...@kimbanet.com
http://www.kimbanet.com/~pjones/default.htm
------------------------------------------------------------------------
Andrew Schultz
> We're not even close to six months after 1.1, and unless 1.1.1 or 1.1.2
6 months is the Firefox policy. SeaMonkey has no policy I know of.
> fixes everything that has gone bad 1.0.7 -> 1.1, this is bad news for
> mailnews users. I wouldn't do it out of principle.
What is it you still see broken in 1.1.x mail?
I think there are a couple good reasons to drop 1.0.x, beyond what
Robert already said.
1. MoFo is dropping support for the 1.8.0 branch next month (so one more
release, perhaps).
2. We maintain quality releases based on feedback from users (I'm
referring here to the more experienced users who file bug reports and
such). These people are going to (if they haven't already) switch to
1.1, and we'll cease to receive bug reports for 1.0.x builds. We'll
have no idea what we're releasing. We could smoketest (not that we have
enough people to do that), but that skims so little of the surface, it's
not going to be helpful.
--
Andrew Schultz
aj...@buffalo.edu
http://www.sens.buffalo.edu/~ajs42/
NoOp
> Until we're ready to put up cadidate builds, please help us testing the
> current 1.8 branch nightlies:
> http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-mozilla1.8/
>
>
> I hope we can get both security update releases in shape and out the
> door soon.
>
Downloaded & installing now on my test machine.
Robert Kaiser
> We're planning to ship SeaMonkey 1.0.8 in parallel with Gecko 1.8.0.10
> (Firefox 1.5.0.10), the first candidate builds are up here:
> http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/candidates-1.0.8/
>
> Windows and Linux builds are there already, I had to rebuild on Mac
> because some tests failed (probably timeouts because the machine was
> busy doing a second build at the same time).
Slightly updated Windows and Linux builds are up (small fix for a mail
folder problem was added), and I just uploaded the Mac builds to the
main FTP servers - mirrors should catch up soon.
Please test those builds extensively and stop by in #seamonkey for
smoketesting - if all goes well, we want to release exactly those builds
as our 1.0.8 release.
Robert Kaiser
Geoff Welsh
> As you might know, new Gecko security updates are planned very soon, see
> http://wiki.mozilla.org/Firefox:1.5.0.10-2.0.0.2
>
> We're planning to ship SeaMonkey 1.0.8 in parallel with Gecko 1.8.0.10
> (Firefox 1.5.0.10), the first candidate builds are up here:
> http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/candidates-1.0.8/
>
RK is probably too busy but can someone explain to me the purpose of
making a 1.0.8 if there is already a 1.1?
I've never developed software, obviously, I just update when I think I
am supposed to and already use 1.1.
thanks
GW
Tony Mechelynck
Not all users upgrade at the same pace.
I'm testing SeaMonkey 1.5a on my home computer (and I'm quite happy with it);
you're on 1.1; I suppose that if there are corporate users of SeaMonkey, many
of them are still on 1.0.x and not willing to switch to 1.1 (which has a
different version of the Gecko rendering engine) until it will have been used
for long enough by enough people to assure their CEOs that they won't lose
business by upgrading. In the meantime, if there are security fixes to the
version they're using, they should get them.
Best regards,
Tony.
--
Q: How many right-to-lifers does it take to change a light bulb?
A: Two. One to screw it in and one to say that light started when the
screwing began.
Anthony M. Davidovich
> I've never developed software, obviously, I just update when I think I
> am supposed to and already use 1.1.
The most people here like SM 1.1. Sure, SM 1.1 has a lot of cool new
fesatures, but there are too many bugs in it comparing to the good SM
1.0.7. This was a 1st time the current release of SM is so buggy.
I'll stay on 1.0.x. Make "no bugs" not "bugs and features" :)
Anthony
David L. Ross
> Geoff Welsh wrote:
>> Robert Kaiser wrote:
>>> As you might know, new Gecko security updates are planned very soon,
>>> see http://wiki.mozilla.org/Firefox:1.5.0.10-2.0.0.2
>>>
>>> We're planning to ship SeaMonkey 1.0.8 in parallel with Gecko
>>> 1.8.0.10 (Firefox 1.5.0.10), the first candidate builds are up here:
>>> http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/candidates-1.0.8/
>>>
>>>
>>
>> RK is probably too busy but can someone explain to me the purpose of
>> making a 1.0.8 if there is already a 1.1?
>>
>> I've never developed software, obviously, I just update when I think I
>> am supposed to and already use 1.1.
>>
>> thanks
>> GW
>
> Not all users upgrade at the same pace.
>
> I'm testing SeaMonkey 1.5a on my home computer (and I'm quite happy with
> it); you're on 1.1; I suppose that if there are corporate users of
> SeaMonkey, many of them are still on 1.0.x and not willing to switch to
> 1.1 (which has a different version of the Gecko rendering engine) until
> it will have been used for long enough by enough people to assure their
> CEOs that they won't lose business by upgrading. In the meantime, if
> there are security fixes to the version they're using, they should get
> them.
>
considers mangled attachments on Mac that big a deal. It's a crisis for
the offices where it happens.
But anyway, v1.0.x is still very important to some of us.
google0214....@spamgourmet.com
> While talking about 1.1.x being the "primary stable releases" now, we're
> also trying to get a SeaMonkey 1.1.1 ready for releasing.
>
> This has seen a good flow of fixes since 1.1, and we'd like to get those
> out to users, ideally, we'd make the date of Gecko 1.8.1.2, but maybe
> we'll need a small bit more time for QA.
Just another user's opinion. I too am hoping for a prompt 1.1.1
release. There are inevitably problems discovered when a x.0 release
gets out into the real world, and SM 1.1.0 is no exception.
In my perfect world the SeaMonkey Council would create 1.1.1 Release
Candidates right now and advertise the availability of those
candidates. Now, while the branch is frozen, is the time to get back
in sync with the 1.8.1 Gecko releases, not in the 6 - 8 weeks until
1.8.1.3.
Andrew Schultz
> The most people here like SM 1.1. Sure, SM 1.1 has a lot of cool new
> fesatures, but there are too many bugs in it comparing to the good SM
> 1.0.7. This was a 1st time the current release of SM is so buggy.
You filed bugs, right?
Benoit Renard
I assumed it would do the same, like with so many other things.
> What is it you still see broken in 1.1.x mail?
The new mail notification. See the release notes.
> 1. MoFo is dropping support for the 1.8.0 branch next month (so one more
> release, perhaps).
I didn't know that. Has it been that long since Firefox 2 already? Then
I guess support for 1.0.x wouldn't be that feasible anymore...
Andrew Schultz
>> What is it you still see broken in 1.1.x mail?
>
> The new mail notification. See the release notes.
I don't see that getting fixed anytime soon. And since it's either rare
or Win9x-only, I don't see it as a reason for people to not switch to 1.1.x.
Robert Kaiser
> We're planning to ship SeaMonkey 1.0.8 in parallel with Gecko 1.8.0.10
> (Firefox 1.5.0.10), the first candidate builds are up here:
> http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/candidates-1.0.8/
We have redone the candidates as the Gecko version was wrong in the
previous ones.
Please help us testing those so we can release them in time. A set of
basic smoketests would really be good to have done on them to prove
they're functional.
Additionally, SeaMonkey 1.1.1 seems to be on its way as well, I have
uploaded candidate builds for Windows and Mac already, Linux will follow
in a few hours:
http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/candidates-1.1.1/
Basic smoketests are the least we need on those - they had much more
extensive changes since the previous version than the other security
release, so more extensive testing should be done there.
Please help us to get the testing we need in order to release those
versions!
Thanks!
Robert Kaiser
Andrew Schultz
> Please help us to get the testing we need in order to release those
> versions!
Right! Please grab the builds and give them a whirl.
Short informal / unscientific survey:
Who here is using a nightly branch build from the 1.8.0 branch from
after 1.0.7 (or a 1.0.8 candidate) for their own daily use?
I know there are people are using 1.1.x because we get feedback, but I'm
curious about 1.0.x builds.
Michael Gordon
I tried downloading and installing the Windows 32 bit Zip file and when
I clicked on the seamonkey.exe I had a few surprises. I placed the Zip
file and the extracted files in a completely different folder than the
SeaMonkey 1.1 program folder. It is my understanding that by using the
Zip file we are not supposed to access anything from the previous
SeaMonkey installations.
When I opened SeaMonkey 1.1.1 I had all my plugins, extensions, themes,
bookmarks, and mail.
What happened? I thought by using the Zipped file nothing could be
written or read from the Windows registry and the new SeaMonkey test
application would not know about the previous version being installed.
Michael
--
Armadillo Web Design
Opening your door of opportunity
Armadillo Web Design
www.armadilloweb.com
Character is doing the right thing...
Even when no one is watching...
SeaMonkey
www.mozilla.org/projects/seamonkey/
The all in one browser, mail, and composer.
SeaMonkey the "All In One Internet Application Suite"
Daniel
Robert, I would love to help, but being on a slow dial-up, I?d spend all
my time d/l?ing and not testing so I don?t think I could contribute much!
What is ?Basic Smonketest? and What is the difference between ?testing?
and ?Smoke Testing??
Daniel
Tony Mechelynck
All your plugins, extensions, themes and mail are in your profile, which is in
a distinct location from the unpacked zipfile (or from the distribution set up
by the installer when you use one). The registry is not involved, except
insofar as it defines where your home directory is located. If you want to use
a separate profile, use one of
seamonkey -ProfileManager
seamonkey -ProfileWizard
or
seamonkey -P <profilename>
Some of them might not work on all versions. Use
seamonkey -h |more
to see which options are offered by your version.
Best regards,
Tony.
--
The average woman would rather have beauty than brains, because the
average man can see better than he can think.
Benoit Renard
extensions that you installed in the application folder, of course.
SeaMonkey probably detected the available plug-ins on your system.
Andrew Schultz
> Robert, I would love to help, but being on a slow dial-up, I?d spend all
> my time d/l?ing and not testing so I don?t think I could contribute much!
Testing builds doesn't necessarily mean you have to download more. If
you grab a candidate for testing, there's a good chance you won't need
to get the release build. It might be that we release the candidate as
the final build, or it might be that we just take a last minute fix that
doesn't matter to you (perhaps we fix a spelling error). If you do
testing of nightly builds before the candidates (which is also very
helpful), then you will spend more downloading builds.
> What is ?Basic Smonketest? and What is the difference between ?testing?
> and ?Smoke Testing??
Smoketesting refers to a testing process we go through before each
release. We go through a preselected list of basic tests. A
smoketester performs each test from a preselected list of basic tests.
If the test fails, the tester notes the failure and files a bug.
Testing outside of smoketesting just refers to grabbing the build and
using it. Despite its informality, this is where the vast majority of
our bug reports come from. So, if you don't have the time to devote to
running the smoketests, please just grab a release candidate, use it,
and file bugs for any problems you encounter.
--
Andrew Schultz
aj...@buffalo.edu
http://www.sens.buffalo.edu/~ajs42/
Peter Potamus the Purple Hippo
> A set of basic smoketests would really be good to have done on them to prove
> they're functional.
>
> Basic smoketests are the least we need on those -
what are smoketests?
--
Peter Potamus & His Magic Flying Balloon:
http://www.toonopedia.com/potamus.htm
http://www.bcdb.com/cartoon/46347-Peter_Potamus_Show.html
http://www.toonarific.com/show.php?s_search=Potamus&Button_Update=Search&show_id=2778
Please do not email me for help. Reply to the newsgroup only. Thanks
Dick Hoffman
improvements to SeaMonkey. Now I see, from this thread, that SM exists
in two parallel worlds; the 1.0.X world and the 1.1.X one. What is the
rationale for following two paths for this product, and more
importantly, which represents the latest and greatest? Which one should
I be following?
Dick
Tony Mechelynck
Which one you should be following is for you to decide.
Sm 1.0.x may still be supported for some time with security fixes. Probably
not much else I guess. Being older than 1.1.x, it might also be stabler, which
can be an asset, especially in the corporate world.
Sm 1.1.x is the latest released version. If you're currently using it, you
shouldn't go back to 1.0.x unless you're having insurmountable problems with
1.1.x; and even so, you should bear in mind that 1.1.x will definitely be
supported longer than 1.0.x.
The latest, but maybe not yet greatest, is Sm 1.5. It is only at the alpha
stage yet. I'm using its Navigator component with no problems but YMMV.
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
46. Your wife makes a new rule: "The computer cannot come to bed."
NoOp
> Additionally, SeaMonkey 1.1.1 seems to be on its way as well, I have
> uploaded candidate builds for Windows and Mac already, Linux will follow
> in a few hours:
> http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/candidates-1.1.1/
>
Linux install seamonkey-1.1.1.en-US.linux-i686.installer.tar.gz creates
a serious problem if not run first in su/sudo/root mode. The remove
directory part will remove several files in the /user/local/seamonkey
directory, then exit after multiple "Permission denied". That can be
expected.
However, when then again trying to re-run in su/sudo mode, it fails
installation because it finds a partial directory. Error [-630]:
Destination directory must be empty or contain a previous installation.
Note: the ./mozilla directories & files are left untouched, so it is not
a total disaster. It is only the /usr/local/seamonkey directory/files
that are affected. Unfortunately, your previous version of SM is hosed
so you then need to download seamonkey-1.1.1.en-US.linux-i686.tar.gz,
unzip that & replace the old /user/local/seamonkey directory with this
new one. After that 1.1.1 comes up just fine.
I guess this would be more appropriate in the developer group, but
wanted to forewarn other users in this group as well.
Andrew Schultz
> On 02/18/2007 02:39 PM, Robert Kaiser wrote:
>
>> Additionally, SeaMonkey 1.1.1 seems to be on its way as well, I have
>> uploaded candidate builds for Windows and Mac already, Linux will follow
>> in a few hours:
>> http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/candidates-1.1.1/
>>
>
> Linux install seamonkey-1.1.1.en-US.linux-i686.installer.tar.gz creates
> a serious problem if not run first in su/sudo/root mode. The remove
> directory part will remove several files in the /user/local/seamonkey
> directory, then exit after multiple "Permission denied". That can be
> expected.
If you run the installer as a normal user and the directory was
installed by root, it shouldn't be able to delete anything.
> However, when then again trying to re-run in su/sudo mode, it fails
> installation because it finds a partial directory. Error [-630]:
> Destination directory must be empty or contain a previous installation.
>
> Note: the ./mozilla directories & files are left untouched, so it is not
> a total disaster. It is only the /usr/local/seamonkey directory/files
> that are affected. Unfortunately, your previous version of SM is hosed
> so you then need to download seamonkey-1.1.1.en-US.linux-i686.tar.gz,
> unzip that & replace the old /user/local/seamonkey directory with this
> new one. After that 1.1.1 comes up just fine.
As the error message suggests, you just need to delete
/usr/local/seamonkey manually to proceed with the installation.
The restriction is there so that you can't install to system
directories, which has catastrophic effects.
--
Andrew Schultz
ajsc...@verizon.net
http://www.sens.buffalo.edu/~ajs42/
NoOp
Well it obviously deleted something, as after running simply as
./seamonkey-installer my previous version of SM (1.1) would *not* run.
I didn't inventory the directory (/user/local/seamonkey) beforehand, but
I have another test machine that has 1.1 on it if you'd like me to try
to reproduce.
Basically the first was:
1. Download & unzip seamonkey-1.1.1.en-US.linux-i686.installer.tar.gz to
it's own directory in a temporary /home/user directory.
2. Brought up an xterm & changed to the
/home/user/tempdir/seamonkey-installer directory
3. From the term did ./seamonkey-installer (note: yes I know that I
should have done sudo./seamonkey-installer but I was working on other
systems at the same time & didn't think about it).
4. SM brought up the standard install windows, I checked "complete
install", said "yes" to delete directory, and SM went on it's way.
Unfortunately the term window scrolled beyond the start, so I could not
see all of the mgs - only the last section that noted "Permission denied".
5. Realized my error & just tried to run my exisiting SM (1.1) from the
panel icon... didn't work.
5. Realized my error & tried to run:
sudo ./seamonkey-installer
6. SM brought up the standard installer window, accepted, complete
install selected again, and that is when I ran into the Error [-630].
7. Fixed the problem by downloading & unzipping
seamonkey-1.1.1.en-US.linux-i686.tar.gz and replacing the entire
directory in /usr/local/seamonkey.
So obviously the installation script *does* change something in the
/usr/local/seamonkey directory. Otherwise just replacing the directory
with the contents of seamonkey-1.1.1.en-US.linux-i686.tar.gz wouldn't work.
I *do* realise (now) that I probably could have proceeded by deleting
the /usr/local/seamonkey directory manualy as you suggest. However I
think it important to keep in mind that new SM 1.1.1 installs will
encounter situations just as I've pointed out above with users that have
less experience and may not even know how to manually delete their
/usr/local/seamonkey directory. They *will* try ./seamonkey-install
without sudo/su/root. So it might be really helpful if there are
explicit warnings (readme, or the install script) that help prevent what
I've just done by accident/negligence.
OS: Linux Kernel 2.6.15-28-386
Ubuntu Dapper 6.061 LTS
Andrew Schultz
Well, I know that it was at least able to delete seamonkey-bin. That's
the file the installer looks for to identify the directory as a
seamonkey directory. My guess is that it deleted all the files and left
all the directories. See below.
> I have another test machine that has 1.1 on it if you'd like me to try
> to reproduce.
Before you try, take a look at the ownership and permissions as
described below.
> /usr/local/seamonkey directory. They *will* try ./seamonkey-install
> without sudo/su/root. So it might be really helpful if there are
> explicit warnings (readme, or the install script) that help prevent what
> I've just done by accident/negligence.
Well, I'd rather prevent what happened to you from happening.
The only two ways I can think of that you would hit what you describe are:
1) /usr/local/seamonkey was world-writable but owned by root.
subdirectories were not world-writable
or
2) /usr/local/seamonkey was owned by you (user, not root) while the
contents were owned by root.
Both of these are bad. The installer should never create an install
like that. A loose umask might have helped, but I don't know how it
would have created different parts with different permissions. The fact
that the situation confuses the installer could be fixed somewhat
(walking the whole directory structure and checking the permission of
each file & directory). But it would be a fairly extensive change for a
rare situation that shouldn't happen in the first place.
Also, the README file included with the installer says:
Note: If you install in the default directory (which is usually
/usr/local/seamonkey), or any other directory where only the root user
normally has write-access, you must start SeaMonkey first as root before
other users can start the program.
It also says:
However, do not use sudo to run the installer as root because that can
damage your profile.
NoOp
> Well, I'd rather prevent what happened to you from happening.
>
> The only two ways I can think of that you would hit what you describe are:
> 1) /usr/local/seamonkey was world-writable but owned by root.
> subdirectories were not world-writable
> or
> 2) /usr/local/seamonkey was owned by you (user, not root) while the
> contents were owned by root.
>
> Both of these are bad. The installer should never create an install
> like that. A loose umask might have helped, but I don't know how it
> would have created different parts with different permissions. The fact
> that the situation confuses the installer could be fixed somewhat
> (walking the whole directory structure and checking the permission of
> each file & directory). But it would be a fairly extensive change for a
> rare situation that shouldn't happen in the first place.
>
I'll have to get back to you later on this. Currently I'm using the
machine to test linux installs/distros, but expect to have it back by
tomorrow to take a detailed look.
Gary
Dick Hoffman
upgrades for SM 1.0.x even though it isn't the most efficient use of
resources. I'll stick with SM 1.1 and look forward to 1.5 when it's
released.
Dick
NoOp
> NoOp wrote:
> Well, I know that it was at least able to delete seamonkey-bin. That's
> the file the installer looks for to identify the directory as a
> seamonkey directory. My guess is that it deleted all the files and left
> all the directories. See below.
I know it left the directories; I'll have to try to reproduce, but I'm
pretty sure that it left some files as well.
>
>> I have another test machine that has 1.1 on it if you'd like me to try
>> to reproduce.
>
> Before you try, take a look at the ownership and permissions as
> described below.
Permissions are as follows for the machine that I installed 1.1.1:
/usr/
owner: root
group: root
owner: RWE
group: RE
others: RE
/usr/local/
same as above
/usr/local/seamonkey/
owner: username
group: username
owner: RWE
group: RE
others: RE
/usr/local/seamonkey/seamonkey-bin
owner: username
group: username
owner: RWE
group: RE
others: RE
On my 3 other test machines w/1.1 the settings are as above *except*
/usr/local/seamonkey/
owner: root
group: root
owner: RWE
group: RWE
others: RE
/usr/local/seamonkey/seamonkey-bin
owner: root
group: root
owner: RWE
group: RE
others: RE
I may have fiddled with the permission settings previously when trying
to get OpenOffice 2.1 to use SeaMonkey to email via SM. However, I can
reset & also willing to try fresh installs etc., on one machine if you'd
like, including installing an earlier version & then updating. My
schedule is pretty much free tomorrow afternoon to test whatever you
think is appropriate.
Thanks.
>
> It also says:
> However, do not use sudo to run the installer as root because that can
> damage your profile.
>
Interesting. If sudo is *not* used, then SM will not have the
permissions to install... confused. Perhaps you're thinking of 'su'
rather than 'sudo'?
Andrew Schultz
> /usr/local/seamonkey/
> owner: username
> group: username
> owner: RWE
> group: RE
> others: RE
>
> /usr/local/seamonkey/seamonkey-bin
> owner: username
> group: username
> owner: RWE
> group: RE
> others: RE
And are any of the subdirectories (under seamonkey/) owned by root? Or
is everything in the directory (and subdirectories) owned by |username|?
This install is sounding like the scenario I described (assuming
something in there is owned by root). If so, then upgrading this
install would result in the bustication you experienced.
> On my 3 other test machines w/1.1 the settings are as above *except*
>
> /usr/local/seamonkey/
> owner: root
> group: root
> owner: RWE
> group: RWE
> others: RE
>
> /usr/local/seamonkey/seamonkey-bin
> owner: root
> group: root
> owner: RWE
> group: RE
> others: RE
Right. If you upgrade a machine with this directory ownership, you
should have no problems.
>> It also says:
>> However, do not use sudo to run the installer as root because that can
>> damage your profile.
>>
>
> Interesting. If sudo is *not* used, then SM will not have the
> permissions to install... confused. Perhaps you're thinking of 'su'
> rather than 'sudo'?
You should use su (not sudo). Based on my reading of the sudo man page
% sudo -H ./seamonkey-installer
should also work and not corrupt your profile. But I haven't actually
tried it. I consider sudo's default behavior here very broken.
NoOp
> NoOp wrote:
>> /usr/local/seamonkey/
>> owner: username
>> group: username
>> owner: RWE
>> group: RE
>> others: RE
>>
>> /usr/local/seamonkey/seamonkey-bin
>> owner: username
>> group: username
>> owner: RWE
>> group: RE
>> others: RE
>
> And are any of the subdirectories (under seamonkey/) owned by root? Or
> is everything in the directory (and subdirectories) owned by |username|?
No. On that system all are owned by username.
As I said, I may have fiddled with the ownership when I was messing
around with OOo 2.1. email option to mail to SM (got it working btw).
I'm going to wipe out the entire directory on another machine and try a
fresh 1.1.1 install (leaving /home/.mozilla intact). I'll try without su
or sudo, and then try with su and sudo to see what the differences turn
out to be. Then I'll try the same with the directory(s) set at user.
This will take awhile so I'll post back later.
Tony Mechelynck
To run the installer, log in as root. This way you need neither su nor sudo,
and you will have the required permissions.
Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
51. You put a pillow case over your laptop so your lover doesn't see it while
you are pretending to catch your breath.
NoOp
>
> To run the installer, log in as root. This way you need neither su nor sudo,
> and you will have the required permissions.
>
>
> Best regards,
> Tony.
Not recommended for Ubuntu:
Andrew Schultz
> To run the installer, log in as root. This way you need neither su nor
> sudo, and you will have the required permissions.
Whoa! Don't log in to X as root. Ever. Logging in on the console as
root is OK. But I know you don't mean that because you said "run the
installer". You want to run the absolute minimum amount of stuff as root.
Using |su| will give a root environment with root permissions in a
terminal and you can do whatever you need to do as root and then exit.
NoOp
>
> As I said, I may have fiddled with the ownership when I was messing
> around with OOo 2.1. email option to mail to SM (got it working btw).
>
> I'm going to wipe out the entire directory on another machine and try a
> fresh 1.1.1 install (leaving /home/.mozilla intact). I'll try without su
> or sudo, and then try with su and sudo to see what the differences turn
> out to be. Then I'll try the same with the directory(s) set at user.
> This will take awhile so I'll post back later.
>
OK, with the proper directory permissions:
/usr/local/seamonkey/
owner: root
group: root
owner: RWE
group: RWE
others: RE
/usr/local/seamonkey/seamonkey-bin
owner: root
group: root
owner: RWE
group: RE
others: RE
attempting to install: ./seamonkey-installer give the appropriate
warning: "Choose another directory because you do not have permission to
install to: ./usr/local/seamonkey"
su is *not* recommended (it needs to be 'su -i' or 'sudo -i' anyway +
password to get to root) and sudo is the proper way (for Ubuntu), see:
https://help.ubuntu.com/community/RootSudo
sudo ./seamonkey-installer works as documented (of course :-).
I figure that my situation was an anomly because I had the directory(s)
set as username rather than root from my previous testing on OOo. But it
might be a good idea to tuck that away in the event that someone else
has done the same & so that SM have a ready response should it come up
in the user group etc.
Thanks Andrew, appreciate the help & patience.
SM 1.1.1 (from the nightly) now running on the 2nd test machine w/no
problems so far. I'll let them both run for a day or two before
updating/testing on this machine as this is my primary 'production' system.
Andrew Schultz
> su is *not* recommended (it needs to be 'su -i' or 'sudo -i' anyway +
There is no -i option to su.
> password to get to root) and sudo is the proper way (for Ubuntu), see:
> https://help.ubuntu.com/community/RootSudo
>
> sudo ./seamonkey-installer works as documented (of course :-).
erm. It's documented to corrupt your profile. Use -H (-i might also
work) or use su.
Tony Mechelynck
Well, IIUC, on Ubunto nobody can log in as root, but there is another account
(created during system install) which has admin privileges. I guess you can
login as that for the short (or maybe not so short, depending) time required
to install SeaMonkey and run it once; and then close SeaMonkey and log out.
Best regards,
Tony.
--
DETERIORATA
Go placidly amid the noise and waste,
And remember what comfort there may be in owning a piece thereof.
Avoid quiet and passive persons, unless you are in need of sleep.
Rotate your tires.
Speak glowingly of those greater than yourself,
And heed well their advice -- even though they be turkeys.
Know what to kiss -- and when.
Remember that two wrongs never make a right,
But that three do.
Wherever possible, put people on "HOLD".
Be comforted, that in the face of all aridity and disillusionment,
And despite the changing fortunes of time,
There is always a big future in computer maintenance.
You are a fluke of the universe ...
You have no right to be here.
Whether you can hear it or not, the universe
Is laughing behind your back.
-- National Lampoon
Steve Wendt
> Well, IIUC, on Ubunto nobody can log in as root
You can if you set root's password (sudo -i, passwd).
Tony Mechelynck
> Tony Mechelynck wrote:
>> To run the installer, log in as root. This way you need neither su nor
>> sudo, and you will have the required permissions.
>
> Whoa! Don't log in to X as root. Ever. Logging in on the console as
> root is OK. But I know you don't mean that because you said "run the
> installer". You want to run the absolute minimum amount of stuff as root.
So? I start the installer from a konsole terminal. Don't you? Session => New
Root Shell. Do whatever you need then exit when finished.
>
> Using |su| will give a root environment with root permissions in a
> terminal and you can do whatever you need to do as root and then exit.
>
Best regards,
Tony.
--
"Might as well be frank, monsieur. It would take a miracle to get you
out of Casablanca and the Germans have outlawed miracles."
NoOp
> NoOp wrote:
>> su is *not* recommended (it needs to be 'su -i' or 'sudo -i' anyway +
>
> There is no -i option to su.
Sorry, should have been su only:
~$ sudo -i
Password:
root@username:~#
~$ su
Password:
root@username:/home/userdirectory#
Either way both change to root.
>
>> password to get to root) and sudo is the proper way (for Ubuntu), see:
>> https://help.ubuntu.com/community/RootSudo
>>
>> sudo ./seamonkey-installer works as documented (of course :-).
>
> erm. It's documented to corrupt your profile. Use -H (-i might also
> work) or use su.
>
Cite please?
Andrew Schultz
> Either way both change to root.
right
>>> sudo ./seamonkey-installer works as documented (of course :-).
>> erm. It's documented to corrupt your profile. Use -H (-i might also
>> work) or use su.
>>
>
> Cite please?
The README included with the installer.
------------
However, do not use sudo to run the installer as root because that can
damage your profile.
------------
Andrew Schultz
> Andrew Schultz wrote:
>> Tony Mechelynck wrote:
>>> To run the installer, log in as root. This way you need neither su
>>> nor sudo, and you will have the required permissions.
>>
>> Whoa! Don't log in to X as root. Ever. Logging in on the console as
>> root is OK. But I know you don't mean that because you said "run the
>> installer". You want to run the absolute minimum amount of stuff as
>> root.
>
> So? I start the installer from a konsole terminal. Don't you? Session =>
> New Root Shell. Do whatever you need then exit when finished.
Um, no. I (and I suspect at least half of all Linux users) don't use
KDE or konsole. And whatever it is that konsole does sounds different
from "log in as root"
NoOp
> NoOp wrote:
>> Either way both change to root.
>
> right
>
>>>> sudo ./seamonkey-installer works as documented (of course :-).
>>> erm. It's documented to corrupt your profile. Use -H (-i might also
>>> work) or use su.
>>>
>>
>> Cite please?
>
> The README included with the installer.
> ------------
> However, do not use sudo to run the installer as root because that can
> damage your profile.
> ------------
>
Thanks, but is there a reference as to why that is the case or cause?
Not debating, just want to know the why & wherefore.
Andrew Schultz
> Thanks, but is there a reference as to why that is the case or cause?
> Not debating, just want to know the why & wherefore.
There are a couple bugs on file to improve Mozilla behavior, but part of
the problem is that sudo is just broken.
sudo does not change any part of the environment to the root
environment. You don't get things like restricted path, umask, aliases
or (for the current situation) a fresh set of environment variables.
HOME is still set to /path/to/user/home. All sudo does is to give you
elevated privileges.
Mozilla uses HOME to determine the profile directory. So if you use
sudo and run some Mozilla program that decides it should poke your
profile, whatever poking it does will be done under root's authority.
If the profile directory doesn't exist, it will be created (and owned by
root). Any files it decides to write to will be owned by root. When
you run the app as yourself, you won't be able to write to the file.
The net effect of this is that you lose the contents of the file.
Now... running the installer shouldn't access your profile at all. The
installer used to launch the app when it was done and (if you invoked
the installer with sudo) your profile was pretty much toast. The
installer no longer starts the app. The installer does still run some
registration stuff and last I checked, this lightly poked the profile.
I filed a bug, but I doubt the problem will get fixed. It's likely that
(if your profile folder already exists) the poking will not result in
any damage, unless there are other things that I missed. But I wouldn't
bet your profile on it.
NoOp
> NoOp wrote:
>> Thanks, but is there a reference as to why that is the case or cause?
>> Not debating, just want to know the why & wherefore.
>
> There are a couple bugs on file to improve Mozilla behavior, but part of
> the problem is that sudo is just broken.
>
Got it. Thanks much for the explaination & help. I'll remember to *not*
use sudo to install SM in the future :-)
Robert Kaiser
> Tony Mechelynck wrote:
>> So? I start the installer from a konsole terminal. Don't you? Session
>> => New Root Shell. Do whatever you need then exit when finished.
>
> Um, no. I (and I suspect at least half of all Linux users) don't use
> KDE or konsole. And whatever it is that konsole does sounds different
> from "log in as root"
konsole is just a terminal application (happens to be the one integrated
with KDE). Calling "New Root Shell" there asks you for the root password
and open a tab with a bash logged in as root. So actually, in this case,
what Tony did is equivalent with "log in as root".
But, of course, not everyone's on KDE, and not every KDE user uses
konsole (and even I open a normal bash terminal there and do "su" there
or even ssh to my local root account.
Robert Kaiser
NoOp
>
> But, of course, not everyone's on KDE, and not every KDE user uses
> konsole (and even I open a normal bash terminal there and do "su" there
> or even ssh to my local root account.
>
> Robert Kaiser
I reinstalled 1.1.1 w/su on all 4 test systems + this one - all went
well, all w/delete directory option selected, all are operational, all
being used, all profiles intact, no problems enountered :-) The only
add-in/extention installed is Preferences Toobar (PrefBar 3.3.4) on all
machines & that came up without any problems as well. Thanks folks.
Gary Lee
Ubuntu 6.061 LTS
Kernel: 2.6.15-28-386
Robert Kaiser
> http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/candidates-1.1.1/
We fixed a few bugs we saw in the last round of candidates, and even
included a fix that should help some of the problem seen with
QuickLaunch in 1.1, and I have put up those new candidates.
Once again, please help us test those builds so we can do a good 1.1.1
release!
Thanks,
Robert Kaiser
NoOp
Loaded & working just fine so far on linux.
BTW:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.8.1.2pre)
Gecko/20070218 SeaMonkey/1.1.1
Shouldn't your UA be showing:
Gecko/20070221 <== :-)
Jeff Wieland
Hmmm. I'm unable to compile either 1.0.8 or 1.1.1 under Solaris 8 with
GTK1. I can get a GTK2 build, but I'm using a number of non-standard
(for Solaris 8 anyway) packages to achieve this. I need to file a
report in buzilla, but here is the error I get from 1.0.8 (it's
essentially the same with 1.1.1):
--
Jeff Wieland
Andrew Schultz
> Hmmm. I'm unable to compile either 1.0.8 or 1.1.1 under Solaris 8 with
> GTK1. I can get a GTK2 build, but I'm using a number of non-standard
> (for Solaris 8 anyway) packages to achieve this. I need to file a
> report in buzilla, but here is the error I get from 1.0.8 (it's
> essentially the same with 1.1.1):
https://bugzilla.mozilla.org/show_bug.cgi?id=234035
You probably want --disable-freetype2
Robert Kaiser
> BTW:
> User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.8.1.2pre)
> Gecko/20070218 SeaMonkey/1.1.1
>
> Shouldn't your UA be showing:
> Gecko/20070221 <== :-)
Nope, my UA is showing the last time I built and updated my working
copy. I'm not using release builds, I'm using self-built versions
(that's why my UA always has a "pre" in the rv: now, while release
builds don't have that "pre".
Robert Kaiser
Jeff Wieland
> Jeff Wieland wrote:
>> Hmmm. I'm unable to compile either 1.0.8 or 1.1.1 under Solaris 8 with
>> GTK1. I can get a GTK2 build, but I'm using a number of non-standard
>> (for Solaris 8 anyway) packages to achieve this. I need to file a
>> report in buzilla, but here is the error I get from 1.0.8 (it's
>> essentially the same with 1.1.1):
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=234035
>
> You probably want --disable-freetype2
>
That works, but so does using an earlier version of Freetype. Obviously
something changed between 1.0.7 and 1.0.8, and between 1.1 and 1.1.1.
--
Jeff Wieland
Eddie-MacG3
Developments in nightly builds of Mozilla Firefox
http://www.squarefree.com/burningedge/
2007-02-26 Trunk builds
Fixed: 371321 - [Security] Memory corruption when onUnload is mixed
with document.write()s.
Comment #7 OstGote! 2007-02-23:
Some references to SeaMonkey...
Scanning thru the bug I __Guess__ things were
fixed in FF 1.5.0.10 & 2.0.0.2.
How about SeaMonkey?
I just don't know enough about these things to tell for sure,
but don't want the SM Release Manager and friends
to miss anything possibly important here.
Thanks,
Eddie
Andrew Schultz
> Fixed: 371321 - [Security] Memory corruption when onUnload is mixed
> with document.write()s.
> Scanning thru the bug I __Guess__ things were
> fixed in FF 1.5.0.10 & 2.0.0.2.
>
> How about SeaMonkey?
It's a gecko issue.
--
Andrew Schultz
aj...@buffalo.edu
http://www.sens.buffalo.edu/~ajs42/