works here (gnome-terminal in gnome with kdm), what for dm and desktop are you using ?

Keywords: (none) => NEEDINFO

Manuel, LXDM and LXDE.

This is a 4B1 with all updates and the bug manifested after the last update to gksu-polkit.

I am downloading 4B2 to install in a fresh VM and see if it still happens.

oki same as in bug 11956 then

*** This bug has been marked as a duplicate of bug 11956 ***

Status: NEW => RESOLVED
Resolution: (none) => DUPLICATE

Not sure if I follow your logic. That bug was "Description of problem:
lxpolkit not starting by default in LXDE, so it is impossible to launch MCC and other drakes from menu"

I have lxpolkit running and no difficulty in using MCC or other drakes.

Richard

Status: RESOLVED => REOPENED
Resolution: DUPLICATE => (none)

OK, I have completed a fresh install of 4B2, taking the installer's option of updating all packages (and incidentally getting rather more than I was expecting to see for such a recent Beta 2 release).

I manually added lxpolkit which, indeed, is still missing from a task-lxde installation, and I am still seeing gksu fail to to what it is (presumably) designed to do.

In its defence I should add that despite appearing to offer the facility it is designed to offer, it nevertheless procalims on the form, above the root identity selector and password entry box, the message:

"System policy prevents executing a program with administration privileges"

This may well be what is happening under the bonnet, but surely the very act of installing gksu implies that the system is required not to sabotage the intention.

PS.

A couple of minutes after trying to start zenmap with gksu I get this message with the title "Unable to run zenmap";

"Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken."

I spent a day poking around in water way too deep for the length of my clue stick and I have jumped to the unsupported conclusion that the problem may lie in gksu-polkit-20131130/libgksu/gksu-process.c

More specifically in the function get_xauth_token

I had tried to strace the command <gksu zenmap> and noticed a failed open call which was looking for a file in

/usr/sharegksu-polkit-1/environment/

It was followed by two or three more similar looking failures in what I took to be alternative locations.

I knew I had a path: /usr/share/gksu-polkit-1/environment/

it contains 'common.variables', so I bodged a symlink to satisfy the malformed path being sought and lo ... it works.

(In reply to Richard Walker from comment #7)
I can not reproduce this on MATE DE. With either Guake terminal or mate-terminal. As Manuel pointed it *must* be a Desktop specific thing. Did you update nowadays? Mate-polkit should obsolete lxpolkit. After that please re-try and share the results. Thanks.

CC: (none) => tarakbumba
Assignee: bugsquad => tarakbumba

(In reply to Atilla ÃNTAÅ from comment #8)
Also running gksu zenmap on lxterminal is ok.

Yes Manuel, I apply every update as it arrives. I think I have seen at least 2 or 3 relating to bug 11956 in the last 7 days. I will undo my workaround and see if they have fixed the malformed path which appears to me to be stopping gksu-polkit from working.... 

Richard

Comment 10, "Yes Manuel" should have read "Yes Atilla" - sorry.

Comment 7, "More specifically in the function get_xauth_token" - big "sorry". That was just WRONG. More on that in a moment.

Comment 8 response:

I removed the symlink to /usr/share/gksu-polkit-1/environment/ which I had created in /usr and had named <sharegksu-polkit-1> and tried again to execute <gksu zenmap> (or anything else for that matter; it doesn't have to be zenmap).

The old behaviour is restored and gksu fails to start anything (everything). So I looked again for the evidence I had found a few days ago which suggested the symlink hack would work. I executed <strace gksu zenmap> and once more found the failed attempts to locate gksu's <common.variables> which is located at /usr/share/gksu-polkit-1/environment/, but this time I looked more closely at the subsequent faild attempts to locate the file. An extract from strace illustrates the problem:

openat(AT_FDCWD, "/usr/local/sharegksu-polkit-1/environment/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_GB.UTF-8/LC_MESSAGES/glib20.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_GB.utf8/LC_MESSAGES/glib20.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_GB/LC_MESSAGES/glib20.mo", O_RDONLY) = 6
fstat(6, {st_mode=S_IFREG|0644, st_size=88807, ...}) = 0
mmap(NULL, 88807, PROT_READ, MAP_PRIVATE, 6, 0) = 0x7f33d54c3000
close(6)                                = 0
openat(AT_FDCWD, "/usr/sharegksu-polkit-1/environment/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/gdmgksu-polkit-1/environment/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/var/lib/menu-xdggksu-polkit-1/environment/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

Having searched with rpmdrake for packages providing files in any of:
/usr/share/gdmgksu-polkit-1/environment/
/var/lib/menu-xdggksu-polkit-1/environment/

it suddenly dawned on me that these paths were also malformed. They should be (I think):
/usr/share/gdm/gksu-polkit-1/environment/
/var/lib/menu-xdg/gksu-polkit-1/environment/

So I did some more poking around and found this code which looks like it could be the real cause:
In gksu-polkit-20131130/common/gksu-environment.vala

public class Environment: Object {
	HashMap<string,Variable> variables;

	construct {
		weak string[] search_path = GLib.Environment.get_system_data_dirs();
		variables = new HashMap<string,Variable>(GLib.str_hash, GLib.str_equal);

		foreach(string path in search_path) {
			string full_path = path.concat("gksu-polkit-1/environment/");
			read_variables_from_path(full_path);
		}
	}


The offending line seems to be
string full_path = path.concat("gksu-polkit-1/environment/");

This seems to expect the paths returned from GLib.Environment.get_system_data_dirs() to be terminated with "/"

Got to go. Vet appointment for dog...

Richard

Any news on this issue? I can not reproduce this problem on Mageia 4 Beta2. GLib.Environment.get_system_data_dirs() works as intended here. May be a file system/ disk / broken installation issue cause this. Please check these first. Otherwise I' ll close this bug report as invalid.

No more news from this end. I still cannot get gksu to work without providing the path it is looking for (when looking for its "common.variables") by means of a carefully named symlink.

Though it may sound very negative, and I understand that your short list of possible causal issues is not intended to be exhaustive, I can only re-state that the problem first appeared on a Cauldron VM installation which has been religiously maintained since Alpha 3 (I think it was 3, might have been 2).

It appeared immediately after a change to gksu, details are blurred but I am sure I could find out from the logs when I get home tonight.

It was immediately apparent on a second VM installation of Beta 2 + updates as detailed in comment 5.

Both VMs exist on the same physical drive which is less than a year old, 500G USB2 external drive. This drive holds the boot OS (Mageia 3) and three other VMs (Windows XP). None of these systems exhibits any srangeness indicative of a faulty drive.

A broken installation is possible. After all, both Cauldron instances were installed following similar choices resulting in a basic LXDE desktop. There have been other problems in Cauldron which are only evident when using LXDE as the sole installed desktop and this could be one more.

Would you like me to package the VM for you to try out? I am sure I can make another one small enough to be a manageable download and still present the problem.

Alternatively I could give you remote access to my Cauldron system and you could try it for yourself. 

Of course, it all works perfectly with the symlink in place repairing the damaged path in gksu's attempt to find its variables, so we could just leave it at that. 

Richard

(In reply to Richard Walker from comment #13)
Thank you for your kind offer. But i prefer fresh install. I downloaded Beta2 iso and gave a try in VirtualBox. Nah, i still can not reproduce this problem. gksu-polkit finds its "common.variables" and GLib.Environment.get_system_data_dirs() returns /usr/share/
So, i still think problem comes from elsewhere. Are you still have lxpolkit btw? As i wrote comment #8 it may create problem. Dunno..

(Hmmm. Must remember to respond through the bug form. All my emails were bounced. Here they are again in unedited order:)

~I'll check.. back in a  mo'

-0-

I thought so, but I wanted to check anyway. One of the recent updates
 removed lxpolkit and replaced it by mate-polkit or somesuch. It was
 around about the time of the Beta 2 release and if not included in
 that, then it was certainly incorporated before the first boot of this
 second Cauldron installation when I updated from the installer option.

 So far as I can tell lxpolkit is no longer available either in the
 lxsession rpm nor in the lxpolkit package which has now been
 eliminated.

 It may be a silly question, but do you know what
 GLib.Environment.get_system_data_dirs() does in order to identify the
 "system" directories? Presumably it looks it up somewhere, and that
 "somewhere" is initialised either by some Mageia-originated code, or
 by some third party code.

 I get the impression that if it is returning a correctly formed path
 to your instance of gksu and not to mine, then maybe there is
 something in your installation which I don't have in mine, possibly
 provided by some envirionment setup pulled in by one of the desktop
 environments you are using which is done differently by LXDE.

 Does that sound like ruubbish? It is only conjecture and speculation...

 R

-0-

And Google was my friend...

 get_system_data_dirs
 Description:
 public weak string[] get_system_data_dirs ()

 Returns an ordered list of base directories in which to access
 system-wide application data.

 On UNIX platforms this is determined using the mechanisms described in
 the  XDG Base Directory Specification In this case the list of
 directories retrieved will be XDG_DATA_DIRS.

 I'm going to have a poke around the XDG stuff installed on my Caldron.
 I've had trouble with that before with LXDE on Mageia 3 but my memory
 isn't supporting me with any details...

 R

-0-

Tried this:

 [root@Cauldron4B2 ~]# env | grep XDG
 XDG_VTNR=1
 XDG_SESSION_ID=1
 XDG_SEAT=seat0

 What should I be doing to determine the value of XDG_DATA_DIRS, or is
 that a red herring?

 R

-0-

I think I might be getting somewhere. I have removed my symlink
 workaround and tried this (it works):

 [richard@Cauldron4B2 ~]$ export
 XDG_DATA_DIRS=/usr/local/share/:/usr/share/ ; gksu zenmap

 So, you have, I reckon, a fully formed XDG_DATA_DIRS environment
 variable on your system, and whatever it is that I have, it is
 returning values which lack the trailing slash.

 I still don't know where my get_system_data_dirs () function is
 getting its answers from, but explicitly creating and correctly
 setting the XDG environment variable works just as well as fudging the
 path with a dodgy symlink.

 R

(In reply to Richard Walker from comment #15)
No; there is definetly something missing in your setup. My installation of default beta2 lxde, returns XDG_DATA_DIRS. You' re missing some packages. May be shared-mime-info ?

Local time is 10:02. I won't be in a position to check for another 10 or 12 hours. 

Do you think it is worth trying a third install to see if I can get it right this time? I would have expected the custom install option, of LXDE as the sole desktop, to work the same for everyone and not withold packages from my installation which it provides for yours. 

I cannot think of anything I did during the installation which was in the slightest way unusual. Indeed, for the second installation, I even refrained from tweaking the installation packages too much as it saves a lot of time, and I don't need this installation for serious work - just for checking gksu.

Richard

(In reply to Richard Walker from comment #17)
I have submitted gksu-polkit-0.0.3-0.git20131130.8.mga4 to core/updates_testing. Please enable core/updates_testing repository and test new package. It should fix your issue. 

And, you were right from the beginning. XDG directories comes from many packages. If one of them not installed gksu-polkit should not fail. I added a patch which exactly addresses this issue (comes from Foresightlinux). Please revert all your handmade changes and give a try to this new release. 

If it solves your problem, please close this bug report. Thanks for your efforts.

Attaboy Attilla! Works a treat. Thanks for a wonderful Christmas present.

Richard

PS. Just a thought... might it not be better for Mageia as a whole if the XDG stuff was sourced from a single dedicated package to be "required" by any other system requiring XDG standardisation?

I hesitate to suggest this because there are far too many examples in Mageia, and Mandriva/Mandrake before it, of things which are not required being "required" (ever tried removing an unneeded sound server to discover you entired system wanting to give up and go home?) but this seems to be a clear case of a genuine "requirement" which does not fly in the face of the generally accepted meaning of the english word (might be a different meaning in american though - maybe that explains how we slithered down this slope into a new dependency hell).

Status: REOPENED => RESOLVED
Resolution: (none) => FIXED