Bug 666256

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

This is probably because you do not have installed ptlib plugins.  What does
ls -lR /usr/lib/ptlib*
show?

If you do not see alsa and v4l2 (and v4l), then the problem is there.

Just install ptlib plugins package and tell ptlib maintainer to:
- make libpt depend on libpt-plugins
- or better, as it is done on debian, put plugins too inside libpt package

I have same problem; no audio devices detected.

The files alsa_pwplugin.so and v4l2_pwplugin.so are only ones under ptlib, those are provided by ptlib-2.6.5-3.el6.x86_64. Is something else missing from ptlib? 

I didn't find separate ptlib-plugins or libpt-plugins for RHEL6.

What does
ls -lR /usr/lib/ptlib*
show?

Attach -d 4 output when starting and closing ekiga 5 sec. later.

###
ls -lR /usr/lib/ptlib*
ls: cannot access /usr/lib/ptlib*: No such file or directory

###
ls -lR /usr/lib64/ptlib*
/usr/lib64/ptlib-2.6.5:
total 4
drwxr-xr-x. 4 root root 4096 Oct  4  2010 devices

/usr/lib64/ptlib-2.6.5/devices:
total 8
drwxr-xr-x. 2 root root 4096 Oct  4  2010 sound
drwxr-xr-x. 2 root root 4096 Oct  4  2010 videoinput

/usr/lib64/ptlib-2.6.5/devices/sound:
total 80
-rwxr-xr-x. 1 root root 81384 Jun 22  2010 alsa_pwplugin.so

/usr/lib64/ptlib-2.6.5/devices/videoinput:
total 92
-rwxr-xr-x. 1 root root 90472 Jun 22  2010 v4l2_pwplugin.so

Created attachment 499766 [details]
debug output, ekiga -d 4

I suppose that ptlib does not read /usr/lib64.  Could you execute:

strace ekiga 2>&1 | grep /usr/lib.*/ptlib

and tell us what it shows.

strace ekiga 2>&1 | grep /usr/lib.*/ptlib

doesn't show anything, but:

strace ekiga 2>&1 |grep -i /usr/li.*pt
open("/usr/lib64/libpt.so.2.6.5", O_RDONLY) = 3
open("/usr/lib64/libcrypto.so.10", O_RDONLY) = 3

Same problem here. I'm not sure about PM statement. Ekiga is useless without fixing this bug. Is there at least any workaround at this moment?

Do you have /usr/lib ?  If not, create it like this:

# cd /usr
# ln -s lib64 lib

and test ekiga.

You can remove the 'lib' link afterwards.

If you have /usr/lib, then create inside a link to /usr/lib64 counterpart.

This is because I think ekiga tries to load directly /usr/lib/ptlib-... instead of /usr/lib64/ptlib-...

I created link in /usr/lib (ptlib-2.6.5 -> /usr/lib64/ptlib-2.6.5/) and run ekiga however no change there.

Three other tests:
cd /usr/lib64/ptlib-* ; ekiga

and
ENV_PTLIB_PLUGIN_DIR=/usr/lib64/ptlib-2.6.5 ekiga

and
ENV_PTLIB_PLUGIN_DIR=/usr/lib64/ptlib ekiga

Same results: Ekiga started, no real devices available, no detected.

Same result as comment 15, no devices detected.

Start ekiga like this:
PTLIB_TRACE_LEVEL=4 ekiga 2>output
and attach the output.

Created attachment 501341 [details]
debug output; PTLIB_TRACE_LEVEL=4 ekiga 2>ekiga.log

PTLIB_TRACE_LEVEL=4 ekiga 2>ekiga.log

The first lines are useful:
   pluginmgr.cxx(93)	PLUGIN	Cannot open plugin directory /usr/lib64/2.6.5/
   pluginmgr.cxx(96)	PLUGIN	Enumerating plugin directory /usr/lib64/opal-3.6.6/

The error is that it uses 2.6.5 instead of ptlib-2.6.5.  Could you create in /usr/lib64 a link ptlib-2.6.5 to 2.6.5 and tell if ekiga works?

Where are the details on how ptlib and opal and ekiga are built on your distribution (what patches, what configure parameters etc.)?

ln -s ptlib-2.6.5 2.6.5
cd /usr/lib64/


PTLIB_TRACE_LEVEL=4 ekiga 2>ekiga.log

And now it works. It's a miracle. ;)

   tlibthrd.cxx(187)   PTLib   Maximum per-process file handles is 1024
   pluginmgr.cxx(96)    PLUGIN  Enumerating plugin directory /usr/lib64/2.6.5/
   pluginmgr.cxx(96)    PLUGIN  Enumerating plugin directory /usr/lib64/2.6.5/devices/
   pluginmgr.cxx(96)    PLUGIN  Enumerating plugin directory /usr/lib64/2.6.5/devices/sound/
   pluginmgr.cxx(96)    PLUGIN  Enumerating plugin directory /usr/lib64/2.6.5/devices/videoinput/
   pluginmgr.cxx(96)    PLUGIN  Enumerating plugin directory /usr/lib64/opal-3.6.6/
   pluginmgr.cxx(96)    PLUGIN  Enumerating plugin directory /usr/lib64/opal-3.6.6/codecs/
   pluginmgr.cxx(96)    PLUGIN  Enumerating plugin directory /usr/lib64/opal-3.6.6/codecs/audio/

You'll find the source RPMs here. Let me know if you need the spec files opened.

ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Workstation/en/os/SRPMS/ekiga-3.2.6-3.el6.src.rpm

ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Workstation/en/os/SRPMS/ptlib-2.6.5-3.el6.src.rpm

Who is the u$*^^%j who added the multilib patch in ptlib??

I tested with older ptlib:
 ptlib-2.6.5-3 triggers this problem in ekiga
 ptlib-2.6.5-1 works with ekiga

(In reply to comment #22)
> Who is the u$*^^%j who added the multilib patch in ptlib??

That would be me. I tried to make ptlib work with multilib, but obviously did not manage to do it right. I'm sure you've noticed by now and are hard at work on a better patch.

The problem is that ptlib generates headers at compile time. These headers differ on 32bit and 64bit but get installed at the same location. And this obviously may not happen.

The original bug for this was bug 605100.

(In reply to comment #24)
> (In reply to comment #22)
> > Who is the u$*^^%j who added the multilib patch in ptlib??
> 
> That would be me. I tried to make ptlib work with multilib, but obviously did
> not manage to do it right. I'm sure you've noticed by now and are hard at work
> on a better patch.

:o)

> The problem is that ptlib generates headers at compile time. These headers
> differ on 32bit and 64bit but get installed at the same location. And this
> obviously may not happen.

I use debian 64bit and ptlib works: it puts them in /usr/lib, and /usr/lib64 is a link to it.  Do you know how can we know if ptlib should install the plugins in /usr/lib or /usr/lib64 ?

> The original bug for this was bug 605100.

I do not have access to it.

Reading these comments it looked like a workaround existed.

(cd /usr/lib64 && ln -s ptlib-2.6.5 2.6.5) 

but it does not work for me. Am I missing something else? I really need this working before I can deploy for our corporate network.

Sorry all. I did a complete fresh install (via kickstart) and tried the above again and it does seem to now detect the devices. I guess I did something else to break things.

Benjamin, wasn't --libdir=/usr/lib64 a good solution for multiarch problem?

The problem still occurs on Scientific Linux 6.1
ekiga.x86_64      3.2.6-3.el6      @anaconda-ScientificLinux-201107271550.x86_64

(cd /usr/lib64 && ln -s ptlib-2.6.5 2.6.5) solves it

Are there any plans to fix this?
As already put, Ekiga is otherwise pretty useless for normal users.

I would like to fix this issue upstream, but I do not know how.
1. What is the problem exactly?
2. Does someone know how to fix it?

Problem still exists in RHEL 6.2. Causes Ekiga to be completely unusable on my laptop. (Thinkpad X200)

To resume the problem: RedHat uses a multilib approach.  Ekiga seems not to work in this case, hence ekiga RedHat  maintainer created ptlib-2.6.5-multilib.patch in ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Workstation/en/os/SRPMS/ptlib-2.6.5-3.el6.src.rpm.  But there is a bug in this patch.  The last lines should not be:

+#ifdef P_64BIT
+#define P_DEFAULT_PLUGIN_DIR "/usr/lib64/" PTLIB_VERSION
+#else
+#define P_DEFAULT_PLUGIN_DIR "/usr/lib/" PTLIB_VERSION
+#endif

but

+#ifdef P_64BIT
+#define P_DEFAULT_PLUGIN_DIR "/usr/lib64/ptlib-" PTLIB_VERSION
+#else
+#define P_DEFAULT_PLUGIN_DIR "/usr/lib/ptlib-" PTLIB_VERSION
+#endif

Can someone with write access to RedHat packages apply the fix?

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

The fix to close this bug is given in comment #37.  It is a RedHat issue, please fix it, it is trivial.

How does Red Hat dare to call their Desktop / Workstation editions "Enterprise" without fixing such bugs??

Nobody feels bad with shipping software which has been identified as completely unusable for more than one year?

We were considering purchasing Workstation subscriptions but it is now forgotten. Rather invest the money in patching such trivial bugs ourselves based on CentOS or Scientific Linux packages.

Very disappointed I am.

Folks,

We do appreciate the feedback on this bug report and look to use reports such as this to guide our efforts at improving our products. That being said, this bug tracking system is not a mechanism for getting support, and as such we are not able to make any guarantees as to the timeliness or suitability of a resolution. Red Hat is focused on prioritizing the needs of our customers at the top of the list.

If this issue is critical or in any way time sensitive, please raise a ticket through your regular Red Hat support channels to make certain that it gets the proper attention and prioritization to assure a timely resolution. 

For information on how to contact the Red Hat production support team, please see:

    https://www.redhat.com/support/process/production/#howto

We are unlikely to buy (or recommend to our own customers) Desktop/Workstation subscriptions if they contain software which is broken from the very beginning and not fixed within one year.
(But I'm aware that the fix may be less trivial than it seems)

I assume getting new customers also belongs to your business model?

This being said, this is no place for a flame war. 
You seem not to be interested in Enterprise desktops, only in servers. This is good too know before investing further in this direction, and I very much appreciate that Red Hat is honest about it by keeping such information public.

I do not understand why people make comments instead of just fixing it.  It takes less time to fix it than to write a comment.

Same issue on 32-bit version, the ln -s workaround in comment #20 is good on 32-bit.

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.

This Bugzilla has been reviewed by Red Hat and is not planned on being addressed in Red Hat Enterprise Linux 6, and will be closed. If this bug is critical to production systems, please contact your Red Hat support representative and provide sufficient business justification.

JUst for the record, the problem still exists in RHEL 6.4

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