Re: DCOP problem after Etch with Kde upgrade
Florian Kulzer wrote: On Tue, Feb 20, 2007 at 08:56:44 +, 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DCOP problem after Etch with Kde upgrade
On Tue, Feb 20, 2007 at 08:56:44 +, 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DCOP problem after Etch with Kde upgrade
Florian Kulzer wrote: On Sat, Feb 17, 2007 at 08:50:46 +, 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DCOP problem after Etch with Kde upgrade
On Sat, Feb 17, 2007 at 08:50:46 +, 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DCOP problem after Etch with Kde upgrade
Florian Kulzer wrote: On Thu, Feb 15, 2007 at 16:03:37 +, 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
DCOP problem after Etch with Kde upgrade
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? Assistance will be appreciated. John. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DCOP problem after Etch with Kde upgrade
On Thu, Feb 15, 2007 at 16:03:37 +, 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
