Opera 10.01
Whiskers
So I fetched the most likely RPM file (for Mandriva 2009 - I'm still using
Mandriva 2008 on this machine) and installed it.
When starting Opera 10.01, an error is reported - that there is a previous
session still running, indicated by the presence of a lock file
~/.opera/lock. I have watched very carefully, and I'm sure that the only
lock file present is the one created by the new Opera session - there is
no other Opera session running, and the lock file appears instantly when I
start Opera.
I have submitted the automated report which the error notice offered.
I uninstalled 10.01 and re-installed the previous 10.00 - but the false
'existing session' error now happens with that version too! So I've gone
right back to 9.64 for the time being.
Has anyone else had this problem - or found a solution so that 10.01 can
be used?
--
-- ^^^^^^^^^^
-- Whiskers
-- ~~~~~~~~~~
Felix Karpfen
>
> When starting Opera 10.01, an error is reported - that there is a previous
> session still running, indicated by the presence of a lock file
> ~/.opera/lock.
>
> Has anyone else had this problem - or found a solution so that 10.01 can
> be used?
The upgrade worked here without problems.
However, I used the Debian version.
My routine for *all* upgrades is to shut down everything, switch to a
console screen and do the upgrade (as root) from the console.
Then I reload the desktop, cross my fingers and open the upgraded
package(s).
So far, I have been lucky.
Felix
--
Felix Karpfen
Public Key 72FDF9DF (DH/DSA)
Whiskers
I just now took a punt with opera-10.10-b1.gcc4.shared.qt3.i386.rpm and so
far it seems to be fine (if five minutes is a good guide!). It also
starts much quicker than 10.00 - which was taking about 40 seconds for me.
I too use a text console to run Mandriva's package manager, and of course
shut down Opera before trying to install a new version (although even that
shouldn't be essential; the system would continue to run the old version
until all users shut it down ... in theory!). It shouldn't be necessary to
shut down anything else.
Felix Karpfen
> On 2009-10-30, Felix Karpfen <fel...@webone.com.au> wrote:
>> My routine for *all* upgrades is to shut down everything, switch to a
>> console screen and do the upgrade (as root) from the console.
>>
>
> I just now took a punt with opera-10.10-b1.gcc4.shared.qt3.i386.rpm and so
> far it seems to be fine (if five minutes is a good guide!).
Sounds the same as my (recommended) .deb package:
"opera_10.01.4682.gcc4.qt3_i386.deb"
> I too use a text console to run Mandriva's package manager, and of course
> shut down Opera before trying to install a new version (although even that
> shouldn't be essential; the system would continue to run the old version
> until all users shut it down ... in theory!). It shouldn't be necessary to
> shut down anything else.
I use the same routine for all my <upgrades|installs>; because I do not
know enough to do anything else :( !
Whiskers
> Whiskers wrote:
>> On 2009-10-30, Felix Karpfen <fel...@webone.com.au> wrote:
[...]
>> I just now took a punt with opera-10.10-b1.gcc4.shared.qt3.i386.rpm and so
>> far it seems to be fine (if five minutes is a good guide!).
>
> Sounds the same as my (recommended) .deb package:
>
> "opera_10.01.4682.gcc4.qt3_i386.deb"
[...]
Apart from the version I'm now using being a "beta-one" ... ;))
Jorgen Grahn
> Whiskers wrote:
>> On 2009-10-30, Felix Karpfen <fel...@webone.com.au> wrote:
>
>>> My routine for *all* upgrades is to shut down everything, switch to a
>>> console screen and do the upgrade (as root) from the console.
...
>> I too use a text console to run Mandriva's package manager, and of course
>> shut down Opera before trying to install a new version (although even that
>> shouldn't be essential; the system would continue to run the old version
>> until all users shut it down ... in theory!). It shouldn't be necessary to
>> shut down anything else.
>
> I use the same routine for all my <upgrades|installs>; because I do not
> know enough to do anything else :( !
I think you are overly paranoid -- Linux ain't Windows. I have always
done my Debian upgrades right at the desktop, something like
su -c 'aptitude update && aptitude safe-upgrade'
If that doesn't work on a live system, it's a bug.
(For Firefox, the install procedure actually says something like
"please tell everyone to restart their Firefoxes now", but that is
highly unusual.)
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Eirik Byrkjeflot Anonsen
> On Sun, 2009-11-01, Felix Karpfen wrote:
>> Whiskers wrote:
>>> On 2009-10-30, Felix Karpfen <fel...@webone.com.au> wrote:
>>
>>>> My routine for *all* upgrades is to shut down everything, switch to a
>>>> console screen and do the upgrade (as root) from the console.
>
> ...
>
>>> I too use a text console to run Mandriva's package manager, and of course
>>> shut down Opera before trying to install a new version (although even that
>>> shouldn't be essential; the system would continue to run the old version
>>> until all users shut it down ... in theory!). It shouldn't be necessary to
>>> shut down anything else.
>>
>> I use the same routine for all my <upgrades|installs>; because I do not
>> know enough to do anything else :( !
>
> I think you are overly paranoid -- Linux ain't Windows. I have always
> done my Debian upgrades right at the desktop, something like
>
> su -c 'aptitude update && aptitude safe-upgrade'
>
> If that doesn't work on a live system, it's a bug.
Define "work" :)
There are some potential problems with this approach. You haven't
tested that the system behaves correctly during a reboot. Your system
now runs a mix of uninstalled (and probably deleted) code and new code.
If there are compatibility mismatches, things can fail in quite subtle
ways.
Most of the time I'm sure it works well, but I usually prefer to do a
complete reboot while I still have some reasonable idea what have
changed, so I can fix anything that broke. But of course, I am paranoid
about such things :)
eirik
Whiskers
As the man said, this isn't Windows. The only time it's necessary to
reboot a Unix or Linux system is to start using a different 'kernel'. But
if you replace something that is 'required' by something else, without
making sure the something else likes the new something, then the something
else might not behave as expected.
As far as I know, Opera isn't 'required' by anything else - but it does
require particular versions of Qt and GTK.
Jorgen Grahn
> Jorgen Grahn <grahn...@snipabacken.se> writes:
>
>> On Sun, 2009-11-01, Felix Karpfen wrote:
>>> Whiskers wrote:
>>>> On 2009-10-30, Felix Karpfen <fel...@webone.com.au> wrote:
>>>
>>>>> My routine for *all* upgrades is to shut down everything, switch to a
>>>>> console screen and do the upgrade (as root) from the console.
>>
>> ...
>>
>>>> I too use a text console to run Mandriva's package manager, and of course
>>>> shut down Opera before trying to install a new version (although even that
>>>> shouldn't be essential; the system would continue to run the old version
>>>> until all users shut it down ... in theory!). It shouldn't be necessary to
>>>> shut down anything else.
>>>
>>> I use the same routine for all my <upgrades|installs>; because I do not
>>> know enough to do anything else :( !
>>
>> I think you are overly paranoid -- Linux ain't Windows. I have always
>> done my Debian upgrades right at the desktop, something like
>>
>> su -c 'aptitude update && aptitude safe-upgrade'
>>
>> If that doesn't work on a live system, it's a bug.
>
> Define "work" :)
>
> There are some potential problems with this approach. You haven't
> tested that the system behaves correctly during a reboot.
I should probably mention that I'm running Debian stable, as a desktop,
so what happens at reboot is (a) something I can handle and (b) if it
breaks, the Debian guys will be pretty ashamed.
> Your system
> now runs a mix of uninstalled (and probably deleted) code and new code.
> If there are compatibility mismatches, things can fail in quite subtle
> ways.
Hasn't happened to me so far. I wonder what Debian promises will
happen ... they *do* restart daemons which get upgraded or depend
heavily on upgraded libraries, and that's why I'm assuming problems
after the upgrade and before reboot would be a bug.
> Most of the time I'm sure it works well, but I usually prefer to do a
> complete reboot while I still have some reasonable idea what have
> changed, so I can fix anything that broke. But of course, I am paranoid
> about such things :)
>
> eirik
I probably would too, if I was running Debian testing or unstable, or
something like that. Or Gnome as a desktop ...
(Not that I know what you're running.)
Felix Karpfen
> On Mon, 2009-11-02, Eirik Byrkjeflot Anonsen wrote:
>>
>> There are some potential problems with this approach. You haven't
>> tested that the system behaves correctly during a reboot.
>
> I should probably mention that I'm running Debian stable, as a desktop,
> so what happens at reboot is (a) something I can handle and (b) if it
> breaks, the Debian guys will be pretty ashamed.
>
>> Your system
>> now runs a mix of uninstalled (and probably deleted) code and new code.
>> If there are compatibility mismatches, things can fail in quite subtle
>> ways.
>
> Hasn't happened to me so far. I wonder what Debian promises will
> happen ... they *do* restart daemons which get upgraded or depend
> heavily on upgraded libraries, and that's why I'm assuming problems
> after the upgrade and before reboot would be a bug.
I also use "Debian stable" and have no ambitions to install
beta-versions of packages.
For what it is worth, here are my to-date "Debian-upgrade" experiences:
1. Most packages would probably upgrade without problems by running the
upgrade from a desktop. Before I burnt my fingers (see below), Debian
caught my oversights and did all the things that I had overlooked (e.g.
closed files that would interfere with the upgrade);
2. Running a "dist-upgrade" from anything other than a console screen
worked but was unsatisfactory. It scored lots of "warnings/error"
messages during the upgrade and I do not know enough to handle the
flagged problems (if they needed actions); and
3. Upgrading the kernel was a disaster; running that upgrade from a
console did not help. If I had read the first paragraph of
"/etc/lilo.conf" before attempting to reboot, *that* would have helped!
Felix Karpfen
Eirik Byrkjeflot Anonsen
> On 2009-11-02, Eirik Byrkjeflot Anonsen <ei...@opera.com> wrote:
[...]
> As the man said, this isn't Windows. The only time it's necessary to
> reboot a Unix or Linux system is to start using a different 'kernel'. But
> if you replace something that is 'required' by something else, without
> making sure the something else likes the new something, then the something
> else might not behave as expected.
Right. So "usually" it will "just work". But I'm paranoid that way.
> As far as I know, Opera isn't 'required' by anything else - but it does
> require particular versions of Qt and GTK.
But opera will still be running the old version of Qt. All the data
files and libraries Qt may try to access are now from a different
version than it expects. I'm sure that has not been extensively tested.
Of course, when only installing a new version of opera, I don't reboot.
Quit opera (all opera instances on the system), upgrade and start opera
again. That's as good as a reboot in this case.
Jorgen Grahn <grahn...@snipabacken.se> writes:
[...]
>> There are some potential problems with this approach. You haven't
>> tested that the system behaves correctly during a reboot.
>
> I should probably mention that I'm running Debian stable, as a desktop,
> so what happens at reboot is (a) something I can handle and (b) if it
> breaks, the Debian guys will be pretty ashamed.
Ah yes. Debian stable tends to have rather few and small changes.
>> Your system
>> now runs a mix of uninstalled (and probably deleted) code and new code.
>> If there are compatibility mismatches, things can fail in quite subtle
>> ways.
>
> Hasn't happened to me so far. I wonder what Debian promises will
> happen ... they *do* restart daemons which get upgraded or depend
> heavily on upgraded libraries, and that's why I'm assuming problems
> after the upgrade and before reboot would be a bug.
They'll restart the daemons, but they won't restart whatever programs
the user have running. They won't restart X, KDE or Gnome. That's
quite a lot of programs that are still running the old versions of
various things.
For example, with KDE you'll now have a local system where two different
versions of various KDE libraries are communicating with each other.
And of course, the old version of KDE will not be able to find its
support files, but get the ones from the newer version instead. Again,
probably not an extensively tested scenario.
>> Most of the time I'm sure it works well, but I usually prefer to do a
>> complete reboot while I still have some reasonable idea what have
>> changed, so I can fix anything that broke. But of course, I am paranoid
>> about such things :)
>>
>> eirik
>
> I probably would too, if I was running Debian testing or unstable, or
> something like that. Or Gnome as a desktop ...
>
> (Not that I know what you're running.)
Debian unstable. Generally with 12 desktops in active use. I hate
rebooting :)
eirik
sinistra
> screen worked but was unsatisfactory. It scored lots of
> "warnings/error" messages during the upgrade and I do not know
> enough to handle the flagged problems (if they needed actions);
> and
>
> 3. Upgrading the kernel was a disaster;
It sounds like your system is completely mucked-up
Try something like this from an Xterm window as root:
#apt-get autoclean;
#apt-get autoremove;
#orphaner;
#rm -f /var/cache/apt/archives/*.deb
#dpkg --purge $(dpkg --list |grep ^rc |awk '{print $2;}');
Use these commands in order, one after another, after the previous
action returns to the '#' prompt.
[better copy and paste those last two and don't leave out the
semicolons]
This will deep clean your trashy system.
If your system survives that, then:
#apt-get update
#apt-get dist-upgrade
You really shouldn't be trying to run Opera 10x with Debian stable
[is that etch or lenny?]
anyway. Switch your apt preferences to ::Sid:
[your editor] /etc/apt/apt.conf
add the following lines:
APT::Cache-Limit 102582912;
APT::Default-Release "sid";
and add the appropriate sources into your
/etc/apt/sources.list:
like:
deb http://ftp.tiscali.nl/debian/ sid main contrib non-free
deb-src http://ftp.tiscali.nl/debian/ sid main contrib non-free
put this in too:
deb http://ftp.tiscali.nl/debian/ experimental main contrib non-free
deb-src http://ftp.tiscali.nl/debian/ experimental main contrib non-free
then you're ready to do an apt-get update and dist-upgrade after the
above cleaning
and sources.list additions.
Now Opera 10x[beta] will work as you would expect.
--
C
Remco Lanting
> You really shouldn't be trying to run Opera 10x with Debian stable
It works fine, as long as you stick to the Qt3 version, which is what
Opera offers by default.
> anyway. Switch your apt preferences to ::Sid:
Telling someone to switch to Sid (unstable for the ones not knowing the
terminology) is not a good idea in my opinion. First it's *unstable* for a
reason, second because Opera is very unlikely to test their packages
against it. At the very least offer testing, since packages actually have
a cooldown period before they're allowed to migrate in there.
Besides that, the Qt4 version of Opera currently doesn't work with the Qt
(4.5.3) shipped in testing/unstable.
--
Remco Lanting
[Unofficial Opera bug tracker links]
http://opera.remcol.ath.cx/bugs |
http://my.opera.com/community/forums/topic.dml?id=217364 |
remco.lanting...@gmail.com
Horst Schnellinger
You tell someone to switch to sid while you're not being able to know if
etch or lenny is the current stable release?
This posting is the greatest shit I ever read.
Naruki Bigglesworth
> You tell someone to switch to sid while you're not being able to know if
> etch or lenny is the current stable release?
> This posting is the greatest shit I ever read.
Just an idiomatic note: in modern jargon, "the shit" is a good thing. As in, "that weed we
smoked was the shit!"
So I think you might be confusing him when you say his post is the greatest shit you ever read.
If you use dumbest, stupidest, or funniest, then shit takes on its normal meaning.
:-)
Felix Karpfen
>>
>> 3. Upgrading the kernel was a disaster;
>
>
> It sounds like your system is completely mucked-up
It would have been well beyond my abilities to salvage my current
OS-system (Debian Lenny), if I had not had a fully operational
alternative (Debian Etch) on the same box.
I mentioned in my previous posting, the error has nothing to do with the
Debian upgrade routines; it was *entirely* mine. As spelled out in my
quoted reference, it is imperative to run the "lilo" command after
upgrading the kernel.
This was the first and the last time that I will make *that* mistake.
Felix
Jorgen Grahn
> On Tue, 03 Nov 2009 18:16:28 +0100, sinistra <sini...@pochtamt.ru> wrote:
>
>> You really shouldn't be trying to run Opera 10x with Debian stable
>
> It works fine, as long as you stick to the Qt3 version, which is what
> Opera offers by default.
>
>> anyway. Switch your apt preferences to ::Sid:
>
> Telling someone to switch to Sid (unstable for the ones not knowing the
> terminology) is not a good idea in my opinion.
Agreed. Doing it *without explaining the consequences* is terrible
advice.
> First it's *unstable* for a
> reason, second because Opera is very unlikely to test their packages
> against it.
Or at least less likely.
When Remco wrote "You really shouldn't be trying to run Opera 10x with
Debian stable" he made it sound as if it wasn't supported and unlikely
to work. I don't know where he got that from.
Eirik Byrkjeflot Anonsen
> * sinistra <sini...@pochtamt.ru> [03-11-09 17:16]:
[...]
>> You really shouldn't be trying to run Opera 10x with Debian stable
>> [is that etch or lenny?]
>
>> anyway. Switch your apt preferences to ::Sid:
[...]
>
> You tell someone to switch to sid while you're not being able to know if
> etch or lenny is the current stable release?
> This posting is the greatest shit I ever read.
No need for uncivility.
I agree that the advice seems a bit misguided. In particular, a blanket
suggestion to switch to the "unstable" branch without any warning of
what that implies.
Of course, many people (me included) is running debian unstable quite
happily, and find that it almost never breaks in a significant way.
However, it does change fast, and there is frequently some level of
breakage for some parts of the system. If having your applications
randomly change behaviour and exhibit minor, random bugginess is not
your idea of fun, debian stable is probably a better choice.
Sinistra may have a small point: I wouldn't be surprised if there are
more developers at opera who are running unstable than stable. Thus the
code may be slightly better tested on unstable (for that reason). But
the difference shouldn't be big. I'm sure we do plenty of testing on
debian stable before we release.
eirik
sinistra
> etch or lenny is the current stable release?
Well, 'etch' is the old-faithful-steady-on-awfully-reliable and
'lenny' is just stable
I assumed everyone knew that.
It's good to see a bit of passion in the old list, this hearty band
of Opera Linux using
brothers and sisters.
Horst Schnellinger writes:
> Of course, many people (me included) is running debian unstable quite
> happily, and find that it almost never breaks in a significant way.
Yes, unstable is pretty stable actually. I usually do a dist-upgrade
on a weekly basis
having made an image of the partition[s] Using Terabyte Image for
Linux as a
precaution.
Debian unstable is a good system to run. Learn what to do when
something goes
wrong, Debian offers an extensive arsenal of solutions for recovery
a sort of
poor man's adventure playground.
Felix Karpfen wrote:
> It would have been well beyond my abilities to salvage my current
> OS-system (Debian Lenny), if I had not had a fully operational
> alternative (Debian Etch) on the same box.
Well done Felix. If you can still get a console in your lenny
partition have a go
with those Debian cleaning procedures.
Enjoy the show.
--
S
Jorgen Grahn
> sinistra wrote:
>
>>>
>>> 3. Upgrading the kernel was a disaster;
>
> I mentioned in my previous posting, the error has nothing to do with the
> Debian upgrade routines; it was *entirely* mine. As spelled out in my
> quoted reference, it is imperative to run the "lilo" command after
> upgrading the kernel.
>
> This was the first and the last time that I will make *that* mistake.
A side note, from someone who no longer uses LILO and cannot read
/etc/lilo.conf (which was your reference). I expect Debian to fix the
boot loader during a kernel upgrade. I am pretty sure it does if you
use grub or yum as your boot loader. Not 100% sure though, since I
almost always build my own kernels and ignore Debian's ...
So unless you had edited /etc/lilo.conf in a non-safe way, I think you
can blame Debian.
BeartoothTpBkR
[...]
> Well, 'etch' is the old-faithful-steady-on-awfully-reliable and 'lenny'
> is just stable
IOW, you imagine everyone runs debian?? And pays attention to all
those offensively cutesy names that it and its offshoots use instead of
honest release numbers?? What rock have you been living under?
--
Beartooth Staffwright, Neo-Redneck Not Quite Clueless Power User
I have precious (very precious!) little idea where up is.
Felix Karpfen
> On Wed, 2009-11-04, Felix Karpfen wrote:
> ...
>> I mentioned in my previous posting, the error has nothing to do with the
>> Debian upgrade routines; it was *entirely* mine. As spelled out in my
>> quoted reference, it is imperative to run the "lilo" command after
>> upgrading the kernel.
...
>
> So unless you had edited /etc/lilo.conf in a non-safe way, I think you
> can blame Debian.
Debian smells of roses. The failures were *totally* mine.
"/etc/lilo.conf" needs additional entries to access the superseded
kernel-image (renamed "vmlinuz.old) and thoughtfully put into all the
correct places by Debian.
Now also fixed!
ceed
wrote:
> On Wed, 04 Nov 2009 11:26:20 -0500, sinistra wrote:
> [...]
>> Well, 'etch' is the old-faithful-steady-on-awfully-reliable and 'lenny'
>> is just stable
>> I assumed everyone knew that. [....]
>
> IOW, you imagine everyone runs debian?? And pays attention to all
> those offensively cutesy names that it and its offshoots use instead of
> honest release numbers?? What rock have you been living under?
>
I do not run Debian or even a "Debian baby" like Ubuntu. But as a Linux
user I keep an eye on the major distro's and even their pet names like
Linux Mint "Gloria", Ubuntu "Jaunty" and Debian "Lenny".
--
> <(((°> ceed
sinistra
> those offensively cutesy names that it and its offshoots use instead of
> honest release numbers?
In the beginning there was only the darkness of meaningless release
numbers then varily there appeared Debra and Ian Murdock and they
begat the word and the word was Debian and cometh to lead in their
stead Bruce Perens of planet Pixar wherein were many characters from
the mystery of computer animation and they called it Toy Story, and
thusly it was decreed these characters were to lead the numberless
versions of Debian migration into timed based cycles and it was good.
Behold the Universal Operating System.
Debian Invictus
--
S
Jorgen Grahn
> On Wed, 04 Nov 2009 11:26:20 -0500, sinistra wrote:
> [...]
>> Well, 'etch' is the old-faithful-steady-on-awfully-reliable and 'lenny'
>> is just stable
>> I assumed everyone knew that. [....]
>
> IOW, you imagine everyone runs debian?? And pays attention to all
> those offensively cutesy names that it and its offshoots use instead of
> honest release numbers?? What rock have you been living under?
Perhaps he has squeezed himself under a potato?
I'm a Debian user ever since Redhat Linux started to suck ten years
ago or so, but I have to admit that I don't know what the release I'm
running is called. I know it's the current stable one, but I can't
say if it's lenny or etch. (Judging from the above, it's lenny.)
Steinar Bang
> Perhaps he has squeezed himself under a potato?
FWIW my home "server" (PII 233...), has been squeezed, if not under, at
least from (a) potato.
It's a 1996 vintage machine I bought off a friend in 1998. I finally got
around to linuxifying it in 1999, as SuSE 6.2. It stayed on that, until
I tried an upgrade to SuSE 6.4 (I think it was) in 2000. The upgrade
failed miserably. So, after a short career with floppy-FW (I needed my
internet access), I installed potato booting from a network install
floppy in the.
I pulled it up to unstable, and stayed there until the relase of sarge,
when I went to stable, and I've stayed on stable ever since, currently
on lenny.
And after this rather impressive show, I've been partial to debian and
debian-derived systems ever since.
But that doesn't stop me from using RH-derived systems when that's
what's available. When I bought the Acer Aspire Ones for my kids and
myself, just before the summer, the plan was to Ubuntu-ify them. But
the "Linpus" (FC8) linux they come with, has a very high "appliance"
factor, so both the kids machine and my own has stayed with "linpus"
ever since.
Sorry for wandering off topic. I digress easily.
10.01 runs fine (or as fine as it can on that kind of vintage hardware)
on a 1996 vintage PII 233 w/128MB RAM.
10.01 also runs fine on an Atom with 1GB of RAM, with Linpus linux. Not
directly downloadable though, because downloading for Fedora only lists
10,11 and 12. But installing the RPM for the dynamic version compiled
with gcc3 and linked with qt3 worked fine. Presumably the statically
linked one would have worked fine as well.