Bug confirmed. Same happens on my system.
The problem is with loading modules. Running from terminal:

1) tdecmshell userconfig
The Trinity ltdl loader was unable to dlopen() the shared library '/opt/trinity/lib/trinity/kcm_userconfig.so' : '/opt/trinity/lib/trinity/kcm_userconfig.so: cannot open shared object file: No such file or directory'

2) tdecmshell serviceconfig
The Trinity ltdl loader was unable to dlopen() the shared library '/opt/trinity/lib/trinity/kcm_serviceconfig.so' : '/opt/trinity/lib/trinity/kcm_serviceconfig.so: cannot open shared object file: No such file or directory'

3) tdecmshell mountconfig
The Trinity ltdl loader was unable to dlopen() the shared library '/opt/trinity/lib/trinity/kcm_mountconfig.so' : '/opt/trinity/lib/trinity/kcm_mountconfig.so: cannot open shared object file: No such file or directory'

4) tdecmshell wineconfig
The Trinity ltdl loader was unable to dlopen() the shared library '/opt/trinity/lib/trinity/kcm_wineconfig.so' : '/opt/trinity/lib/trinity/kcm_wineconfig.so: cannot open shared object file: No such file or directory'


But tdecmshell displayconfig works (with a spew of FIXME warnings). I wonder if this is related to bug 1790, where displayconfig was not fixed, while the other modules were.

Those shared libraries are in /opt/trinity/lib, not in /opt/trinity/lib/trinity/, but if I copy them to /opt/trinity/lib/trinity, the guidance module still don't load properly.

Francois, I believe you use this package --- would you please share your build script?

Note: With tde-guidance are problems for a long time and not have a "nice solution" - see bug 1188. Because of the dependency on HAL, the situation for the R14 is a little worse.

I really do not know if it is worth consider tde-guidance as blocking for R14. Without the "hacks" did not work even in  3.5.13.x.

> I really do not know if it is worth consider tde-guidance as blocking for R14. > Without the "hacks" did not work even in  3.5.13.x.
It's ok for me if you want to remove this bug from the v14.0.0 list and leave it for later. If we can find an easy solution, good! On the other hand, I don't want to hold up v14.0.0 for 6 more months to try to fix this bug first ;-)

displayconfig was completely replaced with a rewritten and much more powerful C++-based system.  The other guidance modules are more or less the same Python-based hacks that were part of Ubuntu many years ago.

I don't think this should block R14 either, but let's just leave it on the list in case someone who is more familiar with Python notices it and can hack it into a partially usable state.  I'm also not sure what out of the remaining modules actually uses HAL; as far as I can tell these are the remaining modules that are still of any use:
 * Disk & Filesystems
 * System Services (probably not converted to Upstart; in any case the only way to disable an Upstart service is to edit or remove its configuration file!)
 * User Management (this one *is* important)
 * Windows Applications

For a description of each part from François, see bug 1790, comment 0.(In reply to Timothy Pearson from comment #6)
> displayconfig was completely replaced with a rewritten and much more
> powerful C++-based system.  The other guidance modules are more or less the
> same Python-based hacks that were part of Ubuntu many years ago.
> 
> I don't think this should block R14 either, but let's just leave it on the
> list in case someone who is more familiar with Python notices it and can
> hack it into a partially usable state.  I'm also not sure what out of the
> remaining modules actually uses HAL; as far as I can tell these are the
> remaining modules that are still of any use:
>  * Disk & Filesystems
>  * System Services (probably not converted to Upstart; in any case the only
> way to disable an Upstart service is to edit or remove its configuration
> file!)
>  * User Management (this one *is* important)
>  * Windows Applications

For a description of each tde-guidance part from François, see bug 1790, comment 0.

In the package tdeadmin is application 'kuser'. What are the differences between kuser from tdeadmins and user management from tde-guidance?

(In reply to Slávek Banko from comment #7)
> 
> In the package tdeadmin is application 'kuser'. What are the differences
> between kuser from tdeadmins and user management from tde-guidance?

Currently, all utilites from tde-guidance are outdated or useless.

displayconfig was replaced by another "displayconfig" integrated in tdebase.

userconfig does the same job as kuser in tdeadmin.

serviceconfig will not work with systemd distribution.

mountconfig is not really useful, I think there are other tools like 'kdf'.

wineconfig does not work anymore, and there are better frontend for wine nowadays


I suggest we do not spend time on fixing tde-guidance, but just keeping the source code as example for python applications using TDE.

(In reply to Francois Andriot from comment #8)
> (In reply to Slávek Banko from comment #7)
> > 
> > In the package tdeadmin is application 'kuser'. What are the differences
> > between kuser from tdeadmins and user management from tde-guidance?
> 
> Currently, all utilites from tde-guidance are outdated or useless.
> 
> displayconfig was replaced by another "displayconfig" integrated in tdebase.

Agreed.

> userconfig does the same job as kuser in tdeadmin.

Not quite.  When I open the "Control Center", by definition, I expect to see a module for controlling users and groups.  kuser is a separate application and appears to be missing features such as setting the user's logon icon.

> serviceconfig will not work with systemd distribution.

That doesn't mean it is useless--Debian still uses sysv init.  I wonder how much effort it would take to make it work with systemd?

> mountconfig is not really useful, I think there are other tools like 'kdf'.

See previous comment regarding userconfig.

> wineconfig does not work anymore, and there are better frontend for wine
> nowadays

You are probably correct here; I wouldn't consider Wine a core part of the system and seeing as Wine automatically embeds itself in the Start menu any missing configuration features should probably be dealt with upstream by adding additional entries in the dedicated Wine menu.
 
> I suggest we do not spend time on fixing tde-guidance, but just keeping the
> source code as example for python applications using TDE.

As far as I can tell three modules require repair.  That is a far cry from what tde-guidance used to be and should be easy enough to handle.

Tim

Created attachment 2261 [details]
mountconfig: port to TQT/TDE

The attached patch is a simple conversion from QT3/KDE3 to TQT/TDE for the mountconfig utility.
It now runs on TDE R14, but it still uses the "MicroHAL.py" library which in turns use the "/usr/bin/lshal" command, which is provided by HAL daemon.

Incorrect kcm library install location fixed in GIT hash 07ce261 (pytdeextensions).

So mountconfig is the only remaining HAL-dependent module then?

(In reply to Timothy Pearson from comment #11)
> Incorrect kcm library install location fixed in GIT hash 07ce261
> (pytdeextensions).
> 
> So mountconfig is the only remaining HAL-dependent module then?

Looks like I introduced an error in the previous commit; fixed in GIT hash aa5db08.

Errors of this form:

Traceback (most recent call last):
  File "/root/TEMP5/tde-guidance-trinity-14.0.0-r131/debian/tmp/opt/trinity/share/apps/guidance/userconfig.py", line 32, in <module>
    from qt import *
ImportError: /usr/lib/python2.7/dist-packages/python_tqt/qt.so: undefined symbol: PyExc_NameError
error: ***failed to import module

fixed in GIT hashes a23242a and (python-tqt) a45cbec (tde-packaging).

Still cannot load guidance modules on my test system; working on other patches.

Errors of this form:

Traceback (most recent call last):
  File "/root/TEMP5/tde-guidance-trinity-14.0.0-r131/debian/tmp/opt/trinity/share/apps/guidance/userconfig.py", line 32, in <module>
    from qt import *
ImportError: PyCapsule_Import could not import module "sip"
error: ***failed to import module

fixed in GIT hashes 80c7008 (sip4-tqt) and 6aca8fe (tde-packaging).

Still cannot load guidance modules on my test system; working on other patches

Errors of this form:

Traceback (most recent call last):
  File "/root/TEMP5/tde-guidance-trinity-14.0.0-r131/debian/tmp/opt/trinity/share/apps/guidance/userconfig.py", line 33, in <module>
    from tdeui import *
ImportError: /usr/lib/python2.7/dist-packages/tdeui.so: undefined symbol: PyList_Type
error: ***failed to import module

fixed in GIT hashes 3dbad98 (python-trinity) and 26b1f63 (tde-packaging).

Still cannot load guidance modules on my test system; working on other patches

Errors of this form:

Traceback (most recent call last):
  File "/root/TEMP5/tde-guidance-trinity-14.0.0-r131/debian/tmp/opt/trinity/share/apps/guidance/userconfig.py", line 33, in <module>
    from tdeui import *
ImportError: /usr/lib/python2.7/dist-packages/python_tqt/qtxml.so: undefined symbol: _Py_NoneStruct
error: ***failed to import module

fixed in GIT hashe e3a99f6 (python-tqt).

Still cannot load guidance modules on my test system; working on other patches.  Each module presents a unique error now, so I am probably getting close.

Comment on attachment 2261 [details]
mountconfig: port to TQT/TDE

Patch verified as functional and pushed to GIT in hash 138f189.

I will work on converting the other modules.

(In reply to Timothy Pearson from comment #17)
> Comment on attachment 2261 [details]
> mountconfig: port to TQT/TDE
> 
> Patch verified as functional and pushed to GIT in hash 138f189.
> 
> I will work on converting the other modules.

Remaining modules converted in GIT hash d28ae74.

userconfig is still not functional on my test system due to a problem importing crypt.

I would like to delete guidance-power-manager as (from what I can tell) it does not provide anything valuable vs. tdepowersave; have I overlooked anything?

Thanks!

Tim, thanks for the huge amount of work you are doing these days. In comparison it's a pretty busy period for me and have little time for TDE.

> That doesn't mean it is useless--Debian still uses sysv init.
Debian/Testing has move to systemd a while ago and should be frozen in November

>I would like to delete guidance-power-manager as (from what I can tell) it does 
>not provide anything valuable vs. tdepowersave; have I overlooked anything?
No objection from me, as long as the same functionality is available both on tdepowersave and kpowersave (for those *bsd system). I may be wrong, but I don't recall (not on a TDE machine now) tdepowersave configuration page to be available from the control panel. In such case it would be good to add an entry under "system administration" to show tdepowersave/kpowersave config page.

(In reply to Michele Calgaro from comment #19)
> Tim, thanks for the huge amount of work you are doing these days. In
> comparison it's a pretty busy period for me and have little time for TDE.
 
No problem; I happen to have some time now to work on TDE again.  It's great to have others working on TDE as well!

> > That doesn't mean it is useless--Debian still uses sysv init.
> Debian/Testing has move to systemd a while ago and should be frozen in
> November

OK, thanks for that info.  We'll still keep it for legacy reasons, but it looks like we need to have an enhancement request filed to add systemd support to the serviceconfig tool.

> >I would like to delete guidance-power-manager as (from what I can tell) it does 
> >not provide anything valuable vs. tdepowersave; have I overlooked anything?
> No objection from me, as long as the same functionality is available both on
> tdepowersave and kpowersave (for those *bsd system). I may be wrong, but I
> don't recall (not on a TDE machine now) tdepowersave configuration page to
> be available from the control panel. In such case it would be good to add an
> entry under "system administration" to show tdepowersave/kpowersave config
> page.

I agree.  As the existing guidance power manager module did not provide a control center module a new enhancement request should be filed to extent tdepowersave in this manner.  My suggestion is to use the randrtray applet/module as an example; it should be possible in a similar manner to load the tdepowersave configuration widget into a control center module.

The remaining problem with userconfig has been fixed in GIT hash 036a002 (pytdeextensions).

There is one other issue I am tracking down regarding incorrect paths and failure to load; once I fix that I think this report can be closed.  The error for all modules shows up once the build tree has been deleted and is:

ImportError: No module named userconfig
error: ***failed to import module

Tim

(In reply to Timothy Pearson from comment #20)
> ImportError: No module named userconfig
> error: ***failed to import module

Fixed in GIT hash 2e3f9c8 (tde-packaging).

Power manager removed in GIT hashes 4ed9fb1 (tde-guidance) and 65c05bc (tde-packaging).

tdepowersave enhancement request filed as Bug 2124.

serviceconfig systemd enhancement request filed as Bug 2125.

Thanks for reporting!