Could you post a screenshot and the exact command you use to launch Synaptic?

Created attachment 2078 [details]
Screenshot of the command being used

I am experiencing this same bug and am thus posting the requested screenshot. The command was *not* manually entered, but is the command that TDE itself put in the command box.

I experience this same bug regardless of whether I use tdesu or tdesudo: I click the icon from the menu, enter the password, and I'm left with just a bouncing cursor for a few seconds. No synaptic loads at all. When using tdesudo, my .xsession-errors outputs the same thing as ABC, but tdesu shows no output to .xsession-errors at all.

Thanks Kristopher, very much appreciated.

This bug gets worse with recent versions of the R14 nightlies: attempting to launch Synaptic from the menu seemingly does nothing, no password dialog is displayed. Going into the menu editor reveals that the Synaptic item *does* have the correct command entered, however the following appears in my .xsession-errors when I click it in the menu:

tdesu: No command specified.
tdesu: Use --help to get a list of available command line options.

Do you have synaptic-trinity installed?

(In reply to Timothy Pearson from comment #6)
> Do you have synaptic-trinity installed?

It doesn't seem to make a difference whether or not synaptic-trinity is installed.

I would like to point out that this worked way back in the days of KDE3, without the use of a DE-specific package.

(In reply to Kristopher from comment #7)
> (In reply to Timothy Pearson from comment #6)
> > Do you have synaptic-trinity installed?
> 
> It doesn't seem to make a difference whether or not synaptic-trinity is
> installed.

Weird.  Thanks for the info.

> I would like to point out that this worked way back in the days of KDE3,
> without the use of a DE-specific package.

Well, KDE was mainstream enough back then that Synaptic had a special hack built in, just for KDE.  Now that KDE is version 4 (coming up on 5), and since we are no longer advertising ourself as KDE (for a number of reasons including gaining the ability to use KDE applications from within TDE) that hack won't work for us any more.

This was seemingly fixed on R14.0.2 on Debian Jessie (the password dialog came up and Synaptic launched when clicking it from the menu), HOWEVER it is again present on R14.0.3-pre2 (no password dialog, no Synaptic when clicking it in the menu).

synaptic-trinity was installed in both cases. Purging and installing synaptic-trinity makes no difference.

I tried to replicate the bug. Installed synaptic from debian archives.
1) As root, no problem.
2) As normal user, if I launch Synaptic *without* ticking "Run as a different user", nothing happens and I see this error in .xsession-errors
"Error creating textual authentication agent: Error opening current controlling 
terminal for the process (`/dev/tty'): No such device or address"
3) As normal user, if I launch Synaptic ticking "Run as a different user" and choosing "root", a dialog is displayed asking the root password. After typing the password, synaptic starts correctly.

I don't see any error related to sudo.

My ~/.xsession-errors file gets the following line when I click Synaptic in the menu:

tdesudo: ERROR: You must provide the name of the executable you want to run as an argument to tdesudo

(ideally, it should use tdesu instead since I prefer not to use sudo)

When viewed in the menu editor, the Synaptic item has the correct command. HOWEVER, when I right-click Synaptic from the menu and select "Put Into Run Dialog", the run dialog appears with nothing entered into the box.

Created attachment 2602 [details]
Run dialog associated with this bug

This is the run dialog after going to TMenu -> System -> Right-click Synaptic -> Put In Run Dialog. Seemingly nothing special, but it should contain something along the lines of "synaptic" "tdesu synaptic" or "tdesudo synaptic".

> tdesudo: ERROR: You must provide the name of the executable you want to run as 
> an argument to tdesudo
Ah ah, this could be a clue. I do not have tdesudo installed on my system The last time I installed it (3 years ago) I had some strange problems and I remove it. Could you try removing tdesudo and see if there is any difference?

> This is the run dialog after going to TMenu -> System -> Right-click Synaptic 
> -> Put In Run Dialog.
I tried this and I can see the name of the executable in the run dialog. Again, rty and see what happens without tdesudo.

I have the feeling this bug may be related to bug 2563

(In reply to Michele Calgaro from comment #13)
> > tdesudo: ERROR: You must provide the name of the executable you want to run as 
> > an argument to tdesudo
> Ah ah, this could be a clue. I do not have tdesudo installed on my system
> The last time I installed it (3 years ago) I had some strange problems and I
> remove it. Could you try removing tdesudo and see if there is any difference?

There is a change to the output in ~/.xsession-errors , but I think you'll agree the change is meaningless and the result is the same:

tdesu: No command specified.
tdesu: Use --help to get a list of available command line options.

> > This is the run dialog after going to TMenu -> System -> Right-click Synaptic 
> > -> Put In Run Dialog.
> I tried this and I can see the name of the executable in the run dialog.
> Again, rty and see what happens without tdesudo.
> 
> I have the feeling this bug may be related to bug 2563

The run dialog is still empty when doing this without tdesudo.

(In reply to Kristopher from comment #9)
> This was seemingly fixed on R14.0.2 on Debian Jessie (the password dialog
> came up and Synaptic launched when clicking it from the menu), HOWEVER it is
> again present on R14.0.3-pre2 (no password dialog, no Synaptic when clicking
> it in the menu).
> 
> synaptic-trinity was installed in both cases. Purging and installing
> synaptic-trinity makes no difference.

I tested with synaptic (package synaptic-trinity installed):
+ TDE 14.0.3-preliminary
+ on Debian Wheezy and Jessie
+ without tdesudo but also with tdesudo
+ all four cases completely fine

(In reply to Kristopher from comment #14)
> (In reply to Michele Calgaro from comment #13)
> > > tdesudo: ERROR: You must provide the name of the executable you want to run as 
> > > an argument to tdesudo
> > Ah ah, this could be a clue. I do not have tdesudo installed on my system
> > The last time I installed it (3 years ago) I had some strange problems and I
> > remove it. Could you try removing tdesudo and see if there is any difference?
> 
> There is a change to the output in ~/.xsession-errors , but I think you'll
> agree the change is meaningless and the result is the same:
> 
> tdesu: No command specified.
> tdesu: Use --help to get a list of available command line options.
> 
> > > This is the run dialog after going to TMenu -> System -> Right-click Synaptic 
> > > -> Put In Run Dialog.
> > I tried this and I can see the name of the executable in the run dialog.
> > Again, rty and see what happens without tdesudo.
> > 
> > I have the feeling this bug may be related to bug 2563
> 
> The run dialog is still empty when doing this without tdesudo.

Tested on R14.0.3-preliminary on Wheezy and Jessie both working correctly. Not observed even one of these problems.

To make sure it isn't just me having this issue, I did the following in order:

1. 'su -' to root
2. rm -rf .qt .trinity .synaptic (I did not have any settings for root)
3. apt-get --purge remove synaptic synaptic-trinity
4. apt-get install synaptic synaptic-trinity
5. Create new 'test' user with no files or settings
6. Log in to TDE as new 'test' user
7. Try to launch Synaptic from menu -- did not work
8. Right click Synaptic in menu and select "Put into run dialog" -- dialog empty
9. Manually type 'synaptic' into Run dialog (without preceding tdesu/tdesudo) -- no password prompt, no Synaptic
10. Check ~/.xsession-errors -- I get the same "you must provide executable" error from tdesudo as described above


Being that this comes from a clean 'test' user with no prior TDE settings, and only *after* purging/reinstalling synaptic and synaptic-trinity *and* removing root's settings for TDE and synaptic, I think it's safe to say that something is definitely broken here.

This is still on R14.0.3-pre. As mentioned before, it was seemingly fixed on R14.0.2.

It's really strange. My test machine with Jessie is a new clean virtual machine - installed last week. This means that the user account is a new one. And as I stated above, I have not noticed any problems.

I can even perform a test to purge / new install synaptic. However, it can not explain the problem, "Put into run dialog".

(In reply to Slávek Banko from comment #18)
<snip>
> I can even perform a test to purge / new install synaptic. However, it can
> not explain the problem, "Put into run dialog".

I have been getting a lot of kicker crashes like these when logging out/rebooting/shutting down and when using the "Put into run dialog" option from TMenu items:

http://crashreport.trinitydesktop.org/?action=detail&crashid=TDECRSH-3f8f109-0fbb13a-4a5242d-bbab819-33e3f06-f1e6b4f-ce1f431

http://crashreport.trinitydesktop.org/?action=detail&crashid=TDECRSH-8b6c76f-3ca7215-a37b506-7511f68-19803fa-bf63228-0ffbbb4

http://crashreport.trinitydesktop.org/?action=detail&crashid=TDECRSH-4b93460-33423f1-6d8967c-57464af-e5daac2-305d0a1-650a84f

Possibly related to the empty dialog issue?

Kris, can you try the following:
1) launch KDCOP (install if necessary)
2) expand kdesktop, then expand KDesktopIface(default), then select 'void popupExecuteCommand(TQString command). 
3)Double click on it. A small dialog opens asking for a command. Type (for example) kalarm and press enter.
4) The 'Run Command' window should open and display 'kalarm' in the command field.

If at any stage this is not happening, please take a snapshot and report back.

Or more quickly, you can just type this from the CLI:
dcop kdesktop default popupExecuteCommand kalarm

(In reply to Michele Calgaro from comment #20)
> Kris, can you try the following:
> 1) launch KDCOP (install if necessary)
> 2) expand kdesktop, then expand KDesktopIface(default), then select 'void
> popupExecuteCommand(TQString command). 
> 3)Double click on it. A small dialog opens asking for a command. Type (for
> example) kalarm and press enter.
> 4) The 'Run Command' window should open and display 'kalarm' in the command
> field.
> 
> If at any stage this is not happening, please take a snapshot and report
> back.

KDCOP seems to not function correctly. It displays with an empty window, and after a few seconds, TWin takes over with a message saying it isn't responding. There don't seem to be any unusual CPU spikes when running it, as if it's completely inactive from start.

(In reply to Michele Calgaro from comment #21)
> Or more quickly, you can just type this from the CLI:
> dcop kdesktop default popupExecuteCommand kalarm

That brings up the Run Command dialog with kalarm inserted. Clicking Run brings up KAlarm without issue.

Created attachment 2623 [details]
Screenshot of malfunctioning KDCOP

That is interesting. dcop is clearly working when used from CLI, but somehow the GUI KDCOP runs into problems.

Are you able to gdb into the not responding kdcop process, block it and report a full stack frame?

gdb --pid <kdcop process id>
ctrl+c to block the running process (if necessary only)
thread apply all bt full


PS: in case we can not reproduce this bug on our machines, would you be able to create a basic Virtual Box VM showing the problem? We can then work on that eventualy.

Created attachment 2626 [details]
Requested backtrace of KDCOP

(In reply to Michele Calgaro from comment #25)
> That is interesting. dcop is clearly working when used from CLI, but somehow
> the GUI KDCOP runs into problems.
> 
> Are you able to gdb into the not responding kdcop process, block it and
> report a full stack frame?
<snip>

Attached

> PS: in case we can not reproduce this bug on our machines, would you be able
> to create a basic Virtual Box VM showing the problem? We can then work on
> that eventualy.

No. I already tried that for a different bug (I forget which one), but my 15+ year old clunker could barely handle booting a VM into a command line (and went "wee wee wee" all the way there).

If I ever wind up with a new(er) machine while this bug is still present, then I'll jump at the chance to create one.

Kris, thanks again for the feedback. Unfortunately it does not provide much to help debugging this issue.
My take so far is that there is a bug somewhere (probably in tdelibs/dcop I think) which is exposed on old hardware but that does not show up on more recent computers. It could be something like a race condition, similar to other things I have seen in the past. I do not think the problem is in KDCOP.

If you leave the DCOP window running for a while (tell Twin to keep the application running) does it come back to "normal" or does it remains in the same unresponsive state?
During the time while the window is unresponsive, is the CPU running at 100% utilization? (your computer is very old so I guess you have a single core one)

(In reply to Michele Calgaro from comment #28)
<snip>
> If you leave the DCOP window running for a while (tell Twin to keep the
> application running) does it come back to "normal" or does it remains in the
> same unresponsive state?

It remains unresponsive and continues to show the same window as in the screenshot, even after walking away from my computer for awhile.

> During the time while the window is unresponsive, is the CPU running at 100%
> utilization? (your computer is very old so I guess you have a single core
> one)

It fluctuates anwhere from 0% to 3% when I leave it idle with KDCOP open, which is normal for my system.

> It fluctuates anwhere from 0% to 3% when I leave it idle with KDCOP open, 
> which is normal for my system.
Interesting, I would have expected a 100% cpu utilization, instead your system is basically free.
This means KDCOP is stucked somewhere, waiting for something that never comes. Probably the same is happening with synaptic and with the 'put in run dialog' issue.

This is probably going to be a very difficult bug to track down, unless we find a way to give you some modified version of the packages and you test and report back each time. The problem is how to get that modified software to you when we need. I will need to discuss with Slavek about it, unless you are able to compile and install TDE components in case I give you a patch.

(In reply to Michele Calgaro from comment #30)
> > It fluctuates anwhere from 0% to 3% when I leave it idle with KDCOP open, 
> > which is normal for my system.
> Interesting, I would have expected a 100% cpu utilization, instead your
> system is basically free.
> This means KDCOP is stucked somewhere, waiting for something that never
> comes. Probably the same is happening with synaptic and with the 'put in run
> dialog' issue.
> 
> This is probably going to be a very difficult bug to track down, unless we
> find a way to give you some modified version of the packages and you test
> and report back each time. The problem is how to get that modified software
> to you when we need. I will need to discuss with Slavek about it, unless you
> are able to compile and install TDE components in case I give you a patch.

Considering I have my entire desktop isntalled via the official TDE repos, I wouldn't feel comfortable trying to do a compile-and-install outside the package manager for fear of messing up dependencies somewhere, and I could never understand the whole "creating a package" side of dpkg anyways. If I would be able to build RPMs and "alien" them into dpkg without messing stuff up, I could try it that way, though I wouldn't expect quick results considering my ancient system would probably be hideously slow at building something as huge as TDE.

If you don't mind using something along the lines of Dropbox or Bittorrent, or if you would be able to upload to either the TDE mirrors or WWW server, I can retrieve packages that way.

> If you don't mind using something along the lines of Dropbox or Bittorrent, or 
> if you would be able to upload to either the TDE mirrors or WWW server, I can 
> retrieve packages that way.
Probably the best way would be to setup a "download" folder on Slavek's repo, where we can make avaiable specific test packages when we need to get someone to test for us (like you in this specific case).
Slavek, what do you think?

confirmed into Fedora 23, yumex-dnf start in normal user but can't install anything

Created attachment 2643 [details]
Screenshot Fedora 23

> cnfirmed into Fedora 23, yumex-dnf start in normal user but can't install 
> anything
Hi, what happens if you launch yumex-dnf with root priviledges? Does it work? Can you install applications?

(In reply to Michele Calgaro from comment #35)
> > cnfirmed into Fedora 23, yumex-dnf start in normal user but can't install 
> > anything
> Hi, what happens if you launch yumex-dnf with root priviledges? Does it
> work? Can you install applications?

show prompt box for root password but won't compare.

> show prompt box for root password but won't compare.
Sorry, not sure to understand what you mean.
Show the box for root passwork. OK.
you type the root password. Then what happened? Was the password accepted? Reject?

(In reply to Michele Calgaro from comment #37)
> > show prompt box for root password but won't compare.
> Sorry, not sure to understand what you mean.
> Show the box for root passwork. OK.
> you type the root password. Then what happened? Was the password accepted?
> Reject?

sorry for my english... the password is accepted but don't happened nothing. in ps aux cannot find yumex-dnf, as if it had been run

> sorry for my english... the password is accepted but don't happened nothing. 
> in ps aux cannot find yumex-dnf, as if it had been run
Ah ok, understand.
Do you have tdesu installed? or tdesudo?
Do you use sudo or not? If so, try installing tdesudo instead of tdesu and see what happen. This time it should ask for your password for sudoing

(In reply to Michele Calgaro from comment #39)
> > sorry for my english... the password is accepted but don't happened nothing. 
> > in ps aux cannot find yumex-dnf, as if it had been run
> Ah ok, understand.
> Do you have tdesu installed? or tdesudo?
> Do you use sudo or not? If so, try installing tdesudo instead of tdesu and
> see what happen. This time it should ask for your password for sudoing

In my package manager i see only tdesudo and it's installed.

> In my package manager i see only tdesudo and it's installed.
Ok, thanks.

(In reply to dmaglio from comment #40)
> In my package manager i see only tdesudo and it's installed.

Is the user you are logged in as allowed to run yum-ex through sudo?

Is there any difference between trying with tdesu or tdesudo? As in, does one run yum-ex but no the other?

(Remeber: tdesu asks for root password, tdesudo asks for your password)

I don't think there will be a difference based on what's happening for me, but maybe Fedora is different somehow.

Kris, what is the status of this bug? Still happening?
If so, can you list your distro and which trinity package you have installed?
Thanks

@Kris, 
if you still see the same problem, can you attach the list of trinity packages that you have installed?
dpkg -l | sort | egrep 'trinity'
I want to see if I can reproduce this problem here.

@Kris
Can you please run this command and attach the result?
tdebuildsycoca --menutest 
Thanks

> tdesudo: ERROR: You must provide the name of the executable you want to run as an 
> argument to tdesudo

Clearly tdesu or tdesudo are invoked without the name of the executable that you want to run.
Since I can't reproduce the problem on my machine nor on 2 clean installs (buster, stretch), I went through the code that open the "put in run dialog" window.
The ialog is opened by a dcop call and the name of the application to run is provided by a Kservice taken from KSycoca cache

Slavek and I are unable to reproduce this bug. 
Given the lack of feedback to comments 43, 44 and 45, we have decided to remove this bug from the R14.0.5 series.
The bug remains open. If the required information is provided, we will take a further look at this and if we can find a way to reproduce it on our machines, we will add the bug back to R14.0.5.