Porteus

after launching "File Manager" as a super user from app panel, i've started getting "KLauncher could not be reached via DCOP" error when trying to run any other app as guest/root from app menu.

i still can run progs trough terminal as root, but that's all.

when i tried to launch konqueror as guest in command line, got another error. smth like "cant talk to klauncher"

cant even prntscreen %(

1. I have the same error: "KLauncher could not be reached via DCOP"
2. Kwrite does not set by default for txt files again

Ahau,

i don't have this error with beta, RC1, RC2, RC3.

it's a known bug with kdesu and Trinity:
http://trinity-users.pearsoncomputing.net/?0::130
i have added a script in /usr/local/bin/kde which runs 'kdeinit' after 'kdesu' automatically. Unfortunately - seems that it doesn't work for applications launched from Kmenu..

i have only one workaround atm for 'konqueror -Super User' mode bug
open terminal -> login as root through 'su' -> launch 'kdeinit' command -> open 'konqueror - Super User' from kmenu

'kdeinit' command must be changing some perms to allow both users using X11 session at the same time. not sure where...
any ideas?
(brokenman - come back to us!)

Could you alter /usr/share/applications/kde/konqerorsu.desktop to execute a new tiny script instead of opening konqueror directly, and make that script run kdeinit, then opens konqueror?

About

2. Kwrite does not set by default for txt files again

Unpacked this arhive profilerc.tar.bz2 and copy this file profilerc to Thanks.

@ fanthom,

I modified my script, /opt/porteus-scripts/konqueror/konq-su to look like this:
This opens konqueror (but makes it open like a browser instead of a filemanager, I haven't figured out how to get the "--profile filemanagement" bit to work), and it does wait until the password is entered before it runs kdeinit. However, it runs kdeinit in the middle of starting up konqueror, so it's still not doing the trick.

I tried '/usr/bin/kdesu konqueror && sleep 1 && kdeinit' but that just made the script wait until I closed konqueror, then it slept 1 second and ran kdeinit. My lack of scripting knowledge is catching up with me! Maybe '/usr/bin/kdesu konqueror && sleep 1; kdeinit'?

I have tried to reproduce that Klauncher error, tipping Start>System>Super User Mode -Terminal and I get no error! or how do you get to it?

Honestly, I already made one little change to V1.0. I hope that cured the bug! -specifically in 004-kde.xzm-

Regards.

Posted after 1 hour 12 minutes 15 seconds:
@brokenman: I am sorry it was too late for final as I read your post concerning the delta to 002-xorg.xzm, better late than never here is it:

http://www.mediafire.com/?ingdu97j7p6q1me

I patched my module and offered it -patched- in an Edit of my post of Google Earth in zxm-modules.

Regards!

@wread, to recreate the error, boot as guest, then go to system -> more applications (it's a sub menu at the bottom of the system list) ->file manager (super user mode). I don't think this problem is associated with the terminal in su mode. I couldn't reproduce it with PCmanFM as super user, either.

@Ahau: Following your instructions I cannot reproduce the error, either. As I changed 004-kde.xzm, my change could be the cure of the error. I added two files to /root, namely .bashrc and .font.conf. My changed module is here:

http://www.mediafire.com/?szhy0ke4x89hqhf

With these changes, the console behaves as it should, indicating user@host, working directory and colors.
Those experimenting the error can try to see if it works for them.

Good luck!

i have a fix for the 'DCOP' bug - will upload it on the server in few hrs.

@Blaze
thanks for the 'kwrite' patch. will upload it on the server too.

btw: if you submit a patch pls preserve full path in a module and correct guest/root permissions. will be easier for me to test it and upload on the server without any extra job from my side.

@wread
same as Blaze: pls upload a patch files only (with a full description what this patch does) and not whole 004-kde.xzm module. it would greatly save my free time

Thanks guys.

@fanthom: Little details make team work effective; you are right, fanthom. Here is my patch to 004-kde.xzm

http://www.mediafire.com/?r9js5cb2ov2oc4m

They are 2 hidden files (.bashrc and .fonts.config), you have to set "view hidden files".
This patch corrects the konsole to show prompts "user@host", working directory and colors. With it, when you quit mc, for instance, you are in the last working directory you were in mc; mc shows in the top panel the current directory you are browsing, etc.

Maybe we should add a link from /home/guest, with appropiate permissions, so the guest also has the correct settings for prompts, colors, etc. That I haven't tested, but should work.

Regards

DCOP fix is on the server now, please test it:
http://ponce.cc/porteus/i486/testing/1.0-fixes

i have also added a patch for correcting user agent string in 32bits (was showing x86_64 - sorry it's my fault).
all fixes will be uploaded to this folder (and another one for 64 bits) so it's worth visiting from time to time

@wread
thanks a lot will test your patch in next couple of days.

Interesting. I also can't reproduce this error in my pre-v1.0 release. I am using the 32bit version from a few days before the final was posted.

"Interesting. I also can't reproduce this error in my pre-v1.0 release."
very good - will you be able to track where regression happened?

Hi,

The cheatcode, "load=Modules", seems not to work again for both 32bit and 64bit Porteus-1. However, activating modules (a lot) after booting, and executing "ls Desktop" (in /root directory with super user root) got the fault " Stale NFS file handle".

Another error, (whether or not I am not sure): at boot stage, system halts and return the error caused by " porteus-1.0.sgn not found"; but it works after rebooting the box.

Thanks for your great effort for this awesome system.