Militantly FREE software support.
Militantly FREE software support.
NavigationUser loginSpam?See spam posts on this site? If so, please don't reply to the spam! Instead, just report the URL to the webmaster. |
DCOP problem after Etch with Kde upgradeAbout a week ago I obtained the latest Etch (Kde version) Yesterday I updated and upgraded the installation - took At the next boot, the Kde Desktop starts to come up and ------------ "Could not read network connection list I don't understand DCOP, but have ascertained there is no How is the file created and how do I find out if the DCOPserver Assistance will be appreciated. John. -- Bookmark/Search this post with: 
|
• Debian Weekly News - Essential reading for any Debian fan. • Documentation - Debian's own authoritative documentation, including installation docs. • FAQ - Got questions about Debian GNU/Linux? • From Windows to Debian - Tips for converting from Windows to Debian GNU/Linux • Package of the Day. • Security - Security information and alerts! • Bug System - Bug tracking and instructions on reporting bugs. • CD Images - Where/how to get Debian GNU/Linux CD images. • Mailing List Subscription - Dozens of Debian-specific support mailing lists! • Mailing List Archives - Searchable archives of Debian's mailing lists. • Free Software Guidelines - Learn Debian's idea of what "free" software really is. • Package Listings - A very valuable tool: searchable, integrated with bug reports. • Apt-Get Sources - Sources for *.debs which are not official Debian packages. • Backports - Unofficial new software packages that have been "back-ported" to work with the Debian stable/official release. • Developer's Corner - Info about the people behind Debian, policies, and how to package *.deb files.
DCOP problem after Etch with Kde upgrade
On Thu, Feb 15, 2007 at 16:03:37 +0000, john gennard wrote:
> About a week ago I obtained the latest Etch (Kde version)
> from Debian.org and installed it without any problems.
>
> Yesterday I updated and upgraded the installation - took
> many hours on a dialup connection (60 Mb, 58 packages,
> mainly Kde - no packages were deleted). There were no
> problems reported with the upgrading.
>
> At the next boot, the Kde Desktop starts to come up and
> then stops with the following error message:-
>
> ------------
> There was an error setting up inter-process communications
> for KDE. The message returned by the system was:-
>
> "Could not read network connection list
> /home/john/.DCOPserverleary_clara.co.uk__0.
> Please check that the dcopserver program is running."
> ------------
>
> I don't understand DCOP, but have ascertained there is no
> .DCOPsever file in /home/john as there is on two other boxes
> running Etch (these need upgrading, but I'm hesitant to do
> so as I feel this problem can be due only to the upgrade).
>
> How is the file created and how do I find out if the DCOPserver
> is running?
The DCOP server should be started directly by kdeinit; DCOP is the
communication protocol of the various KDE components and programs (see
http://en.wikipedia.org/wiki/Dcop). If KDE is running you should see
something like this:
$ ps -ef | grep [d]cop
florian 18725 1 0 19:10 ? 00:00:00 dcopserver [kdeinit] --nosid
(This command does not help you at the moment since your KDE does not
start up at all if I understand you correctly.)
The DCOP server itself is responsible for creating the file that is
mentioned in your error message (as far as I know).
Something fundamental seems to be wrong with your KDE. With Etch being
frozen I would not expect that a dist-upgrade can make a difference, but
I would try it nevertheless. You might simply have an inconsistent
combination of KDE packages right now, with some old packages still
hanging around. (Upgrading at the wrong moment could also cause a
situation like this; in such a case another upgrade at a later time
might be enough to fix everything.)
--
Regards,
Florian
--
try 'dist-upgrade'
Even if you're only using 'etch', try an 'apt-get dist-upgrade'. Did you notice if you had a long list of 'packages held back' ?
One reason for DCOP failing is permissions on the /tmp directory - just check that it is 'drwxrwxrwt'. Incorrect permissions will cause many necessary bits to fail.
DCOP problem after Etch with Kde upgrade
Florian Kulzer wrote:
> On Thu, Feb 15, 2007 at 16:03:37 +0000, john gennard wrote:
>
>>About a week ago I obtained the latest Etch (Kde version)
>>from Debian.org and installed it without any problems.
>>
>>Yesterday I updated and upgraded the installation - took
>>many hours on a dialup connection (60 Mb, 58 packages,
>>mainly Kde - no packages were deleted). There were no
>>problems reported with the upgrading.
>>
>>At the next boot, the Kde Desktop starts to come up and
>>then stops with the following error message:-
>>
>>------------
>>There was an error setting up inter-process communications
>>for KDE. The message returned by the system was:-
>>
>>"Could not read network connection list
>>/home/john/.DCOPserverleary_clara.co.uk__0.
>>Please check that the dcopserver program is running."
>>------------
>>
>>I don't understand DCOP, but have ascertained there is no
>>.DCOPsever file in /home/john as there is on two other boxes
>>running Etch (these need upgrading, but I'm hesitant to do
>>so as I feel this problem can be due only to the upgrade).
>>
>>How is the file created and how do I find out if the DCOPserver
>>is running?
>
>
> The DCOP server should be started directly by kdeinit; DCOP is the
> communication protocol of the various KDE components and programs (see
> http://en.wikipedia.org/wiki/Dcop). If KDE is running you should see
> something like this:
>
> $ ps -ef | grep [d]cop
> florian 18725 1 0 19:10 ? 00:00:00 dcopserver [kdeinit] --nosid
>
> (This command does not help you at the moment since your KDE does not
> start up at all if I understand you correctly.)
You understand me correctly. Yes the command does not produce
any output on this box. It does of course on three other boxes
running Etch (however none has been upgraded)
> The DCOP server itself is responsible for creating the file that is
> mentioned in your error message (as far as I know).
>
> Something fundamental seems to be wrong with your KDE. With Etch being
> frozen I would not expect that a dist-upgrade can make a difference, but
> I would try it nevertheless. You might simply have an inconsistent
> combination of KDE packages right now, with some old packages still
> hanging around. (Upgrading at the wrong moment could also cause a
> situation like this; in such a case another upgrade at a later time
> might be enough to fix everything.)
>
I can't see any old Kde packages hanging around. A dist-upgrade
has been run (another 30 Mb just covering two days, most accounted
for by Kde packages!) - as you expected it has made no significant
difference although there is a slight change in the behaviour of the
'frozen' Kde blue screen.
Also, in the Xorg log file there is an error message:-
"(EE) AIGLX: screen 0 is not DRI capable"
(I missed this earlier).
Now, I intend to upgrade another box to see what happens and also
to ask on the Kde list in case others have seen this difficulty.
Regards,
John.
--
DCOP problem after Etch with Kde upgrade
On Sat, Feb 17, 2007 at 08:50:46 +0000, john gennard wrote:
> Florian Kulzer wrote:
[...]
> >The DCOP server itself is responsible for creating the file that is
> >mentioned in your error message (as far as I know).
> >
> >Something fundamental seems to be wrong with your KDE. With Etch being
> >frozen I would not expect that a dist-upgrade can make a difference, but
> >I would try it nevertheless. You might simply have an inconsistent
> >combination of KDE packages right now, with some old packages still
> >hanging around. (Upgrading at the wrong moment could also cause a
> >situation like this; in such a case another upgrade at a later time
> >might be enough to fix everything.)
> >
> I can't see any old Kde packages hanging around. A dist-upgrade
> has been run (another 30 Mb just covering two days, most accounted
> for by Kde packages!) - as you expected it has made no significant
> difference although there is a slight change in the behaviour of the
> 'frozen' Kde blue screen.
>
> Also, in the Xorg log file there is an error message:-
> "(EE) AIGLX: screen 0 is not DRI capable"
> (I missed this earlier).
I am pretty sure that this does not cause the DCOP problem.
> Now, I intend to upgrade another box to see what happens and also
> to ask on the Kde list in case others have seen this difficulty.
I kind of lost track of this thread; did we already talk about the
permissions of the /tmp directory? They should be like this:
$ ls -ld /tmp
drwxrwxrwt 16 root root 8192 2007-02-19 18:49 /tmp
--
Regards,
Florian
--
DCOP problem after Etch with Kde upgrade
Florian Kulzer wrote:
> On Sat, Feb 17, 2007 at 08:50:46 +0000, john gennard wrote:
>
>>Florian Kulzer wrote:
>
> [...]
>
>>>The DCOP server itself is responsible for creating the file that is
>>>mentioned in your error message (as far as I know).
>>>
>>>Something fundamental seems to be wrong with your KDE. With Etch being
>>>frozen I would not expect that a dist-upgrade can make a difference, but
>>>I would try it nevertheless. You might simply have an inconsistent
>>>combination of KDE packages right now, with some old packages still
>>>hanging around. (Upgrading at the wrong moment could also cause a
>>>situation like this; in such a case another upgrade at a later time
>>>might be enough to fix everything.)
>>>
>>
>>I can't see any old Kde packages hanging around. A dist-upgrade
>>has been run (another 30 Mb just covering two days, most accounted
>>for by Kde packages!) - as you expected it has made no significant
>>difference although there is a slight change in the behaviour of the
>>'frozen' Kde blue screen.
>>
>>Also, in the Xorg log file there is an error message:-
>> "(EE) AIGLX: screen 0 is not DRI capable"
>>(I missed this earlier).
>
> I am pretty sure that this does not cause the DCOP problem.
>
>>Now, I intend to upgrade another box to see what happens and also
>>to ask on the Kde list in case others have seen this difficulty.
>
> I kind of lost track of this thread; did we already talk about the
> permissions of the /tmp directory? They should be like this:
>
> $ ls -ld /tmp
> drwxrwxrwt 16 root root 8192 2007-02-19 18:49 /tmp
No, we didn't talk of this. However, I did look at the permissions
but clearly not carefully enough (old age is no excuse - I must
concentrate more!). Now, looking again, I find a difference between
what shows up for the box that has the problem and two other installs
which do not:-
drwxrwxrwt 6 root root 4096 2007-02-20 07:55 /tmp Broken Box
drwxrwxrwt 7 root root 4096 2007-02-20 08:00 /tmp Working Box
drwxrwxrwt 7 root root 4096 2007-02-20 08:11 /tmp Laptop
Trying to jog my memory, I think that means a hard link is missing.
If that's correct I need to find which is missing and create it.
Regards,
John.
--
DCOP problem after Etch with Kde upgrade
On Tue, Feb 20, 2007 at 08:56:44 +0000, john gennard wrote:
> Florian Kulzer wrote:
[...]
> >I kind of lost track of this thread; did we already talk about the
> >permissions of the /tmp directory? They should be like this:
> >
> >$ ls -ld /tmp
> >drwxrwxrwt 16 root root 8192 2007-02-19 18:49 /tmp
>
> No, we didn't talk of this. However, I did look at the permissions
> but clearly not carefully enough (old age is no excuse - I must
> concentrate more!). Now, looking again, I find a difference between
> what shows up for the box that has the problem and two other installs
> which do not:-
>
> drwxrwxrwt 6 root root 4096 2007-02-20 07:55 /tmp Broken Box
> drwxrwxrwt 7 root root 4096 2007-02-20 08:00 /tmp Working Box
> drwxrwxrwt 7 root root 4096 2007-02-20 08:11 /tmp Laptop
>
> Trying to jog my memory, I think that means a hard link is missing.
> If that's correct I need to find which is missing and create it.
/tmp does not need to have the same number of hard links on each system;
it depends on how many programs/services create files and directories in
/tmp. What you see is possibly a symptom of the failure to start the
DCOP server, but most likely not its cause. I was worried about the
write permissions for "other" in /tmp, but that seems to be OK.
I would propose that you re-post your question on debian-kde. A number
of people with in-depth knowledge of the KDE internals read this list.
Make sure, however, that you have a subject line which has all the
relevant keywords and the error message to attract the attention of the
these people.
--
Regards,
Florian
--
DCOP problem after Etch with Kde upgrade
Florian Kulzer wrote:
> On Tue, Feb 20, 2007 at 08:56:44 +0000, john gennard wrote:
>
>>Florian Kulzer wrote:
>
> [...]
>
>> [....]
>>
>>No, we didn't talk of this. However, I did look at the permissions
>>but clearly not carefully enough (old age is no excuse - I must
>>concentrate more!). Now, looking again, I find a difference between
>>what shows up for the box that has the problem and two other installs
>>which do not:-
>>
>>drwxrwxrwt 6 root root 4096 2007-02-20 07:55 /tmp Broken Box
>>drwxrwxrwt 7 root root 4096 2007-02-20 08:00 /tmp Working Box
>>drwxrwxrwt 7 root root 4096 2007-02-20 08:11 /tmp Laptop
>>
>>Trying to jog my memory, I think that means a hard link is missing.
>>If that's correct I need to find which is missing and create it.
>
>
> /tmp does not need to have the same number of hard links on each system;
> it depends on how many programs/services create files and directories in
> /tmp.
I think all should be the same. When I'm upgrading Debian by new
installs, I don't select packages, I just let the default selection
go in. All my hardware is the same (but different speeds,
manufacturers etc), and the same CD as media. After installs when all
works well, I cull packages I don't need and install my own
'peculiarities' (e.g. I use getmail, nullmailer and mutt for Mail).
I've looked for 'missing' packages by printing out 'dpkg -l' on three
boxes - all are identical down to versions.
> What you see is possibly a symptom of the failure to start the
> DCOP server, but most likely not its cause. I was worried about the
> write permissions for "other" in /tmp, but that seems to be OK.
All the dcop packages on the working boxes are in the problem one,
dcop is not asked to start and despite blundering around I've been
unable to discover from where and how that message should originate.
> I would propose that you re-post your question on debian-kde. A number
> of people with in-depth knowledge of the KDE internals read this list.
> Make sure, however, that you have a subject line which has all the
> relevant keywords and the error message to attract the attention of the
> these people.
I've just subscribed to debian-kde and will refer the problem to
them as you suggest. I did ask on kde-linux; I got replies but none
helped. Frankly, before getting this email, I had decided to get
the latest CD1-Kde and reinstall from that. Now, I'll wait until I
get replies from debian-kde - I have plenty of time to see if a
solution can be found - anyhow, I'm getting 'bloody-minded' and
would like to know why what works on one box does not on other
'identical' ones.
Florian, you've spent a lot of time helping me. I think you've done
quite enough. If I do get a resolution, I'll let you know how it was
achieved.
My gratitude to you for putting up with an old duffer,
Sincere regards,
John.
--