Edgy uses gksu instead of gksudo (gconf schema not registed)

Does gksudo work with your password?

after looking at the man page i found that gksu is the front end for the su password (not set up unless you manully set it up) IMHO i dont recommend setting it up. gksudo is the front end for sudo. let me know if gksudo works with your user password.

Oh, you're correct, gksudo works. In that case, my original title is quite misleading. It should probably be changed.

Anyway, it seems like gksu has become the default password input. First thing, it is used in the System → Administration menu when launching Synaptic. That can easily be changed to gksudo by using Alacarte, but that's not the only place it is in use.

When launching the update-manager without administrator privileges (which it does unless run from a terminal), and pressing the Install Updates button, gksu pops up asking for the password.

I tried Add/Remove in the Applications menu, and it also uses gksu. This isn't doesn't "affect" gksu, though, but I don't know which package to switch it to. ubuntu-meta?

Thanks for your bugreport.

We use gksu (instead of gksudo) since some time (~dapper). We use a gconf option to turn gksu into gksudo by default.

Please tell me the output of:
$ gconftool-2 --get /apps/gksu/sudo-mode

Thanks,
 Michael

Oh, you're using a gconf option to ease the process of repacking from Debian, right?

When I input that command, it returns that there's no value set. The option must have been lost sometime during the dist-upgrade!

I have exactly the same problem here ! The value is not defined. Could you tell us what to do to put it back to "normal" (and make sure that dist-upgraders don't get this unset) ?

Do you have a file called /etc/gksu.conf? If so, can you please attach it to this bugreport?

Thanks,
 Michael

I do not have one, at least.

I don't have one either.

I do not have one either but i also wasnt able to repoduce this bug on edgy

I do have one edgy machine (that I have dist-upgraded from dapper, maybe 1
month ago) that does not have this problem. The other machine is also a
dist-upgraded dapper, but I did that on yesterday. It has the problem.

Okay. I was impatient. I did this:
gconftool-2 --set /apps/gksu/sudo-mode True --type boolean

Problem fixed. Could this be automagically repaired for others through an update, or that is not possible?

Thanks for the fix, Jeff. Maybe this should somehow be made possible to correct by doing an dpkg-reconfigure gksu? If that would make automagical correction easier, I mean.

Even though it happens to few people during the dist-upgrade process, an average user hit by this problem wouldn't know what to do when his password suddenly stopped working, and thus it's a bug that's very important to sort out before 6.10's release.

We could try this as a last report thing. But I would really prefer if we find the reason for the gconf problem.

Can you please post the upgrade logs from the machine that this problem happend? It should be in /var/log/dist-upgrade/*

There've been several occasions where the Update Manager did dist-upgrades after I went from Dapper to Edgy, so my logs for the real upgrade are no longer there. Let's hope they're still in place on Jeff's machine.

It won't be on my machine: I use dist-upgrade for *ANY* update (I don't see what apt-get upgrade can be useful for...). I think the logs must have ben overwritten a lot of times.

Actually.. on the computer that has the bug... the folder is empty! No logs O_O? On this laptop (which did not have the bug), the log files were present. I opened them with gedit and searched for gksu and found nothing.

Thanks for the additional information.

What is the output of
$ gconftool-2 --get /apps/gksu/sudo-mode

is on affected system (not on those where you fixed the error by hand).

Thanks,
 Michael

Before fixing the string, it returned that no value was set.

For systems where the bug was not present (if I understood your question
correctly), that means where the gconf key was already present, the output
is "true".

On affected systems, where a gconf key does not exist (that is valid for any
case, not just sudo-mode), gconftool-2 will warn you that there is no
defined value for that key.

I am not affected by this bug but i tried the command and the output is true.

Another option to fix this issue would be to add code to gksu to run "gconf_client_get_without_default()" on sudo mode and check if we get a NULL. If so, there was something wrong with the schema and we use a default value of TRUE (for sudo mode). This is a hack would it would ensure that gksu wouldn't fail.

I uploaded a new version of libgksu2 that adds a extra bit of paranoia. If sudo-mode is false it will check if there is a schema for it and if there is none it will assume that the system is hit by this bug and work-around it.

Cheers,
 michael

Is the new package already in the repos? I'm asking because I am also affected from the bug and it still exists on my machine.

Thanks,
Jochen!