1. For the massive stat()ing: in progress.

2. For the missing audio plugin: Sure it says "Codec" and sure you installed libpt-plugins-XXXXX?


Seem to be two differents things to me, the massive stat()ing is a bug, the missing "Codec" (?) is an installation issue. 1. might disappear when plugins are installed.

J.

I just got a reply by email, I paste it here, for the record.

-----------------------------------

> 1. For the massive stat()ing: in progress.  

Yes? I didn't find any other bugzilla reports or I would have just added my
data there. But I find bugzilla virtually unusable. I could have missed it.

On that note, feel free to add this data to the bug report but I'm at work now
and not about to go through all the hoops bugzilla requires to update the bug
report.

> 2. For the missing audio plugin: Sure it says "Codec" and sure you installed
> libpt-plugins-XXXXX?  

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name                       Version                    Description
+++-==========================-==========================-====================================================================
ii  libpt-1.10.0               1.10.1.dfsg-1              Portable Windows Library
un  libpt-1.8.2                <none>                     (no description available)
un  libpt-1.8.3c2              <none>                     (no description available)
un  libpt-1.8.3c2a             <none>                     (no description available)
un  libpt-1.8.7                <none>                     (no description available)
ii  libpt-cvs                  20060907-01-sid.1          Portable Windows Library
ii  libpt-cvs-dev              20060907-01-sid.1          Portable Windows Library development files
ii  libpt-cvs-plugins-alsa     20060907-01-sid.1          PWLib Audio Plugins for ALSA
un  libpt-cvs-plugins-audio    <none>                     (no description available)
ii  libpt-cvs-plugins-avc      20060907-01-sid.1          PWLib Video Plugins for AVC FireWire (IEEE1394)
ii  libpt-cvs-plugins-dc       20060907-01-sid.1          PWLib Video Plugins for DC FireWire (IEEE1394)
ii  libpt-cvs-plugins-oss      20060907-01-sid.1          PWLib Audio Plugins for OSS
ii  libpt-cvs-plugins-v4l      20060907-01-sid.1          PWLib Video Plugins for Video4Linux
ii  libpt-cvs-plugins-v4l2     20060907-01-sid.1          PWLib Video Plugins for Video4Linux2
un  libpt-cvs-plugins-video    <none>                     (no description available)
pn  libpt-dev                  <none>                     (no description available)
ii  libpt-plugins-alsa         1.10.1.dfsg-1              Portable Windows Library Audio Plugin for the ALSA Interface
ii  libpt-plugins-avc          1.10.1.dfsg-1              PWLib Video Plugin for IEEE1394 (FireWire) AVC devices
un  libpt-plugins-dc           <none>                     (no description available)
ii  libpt-plugins-oss          1.10.1.dfsg-1              Portable Windows Library Audio Plugins for the OSS Interface
ii  libpt-plugins-v4l          1.10.1.dfsg-1              Portable Windows Library Video Plugin for Video4Linux
ii  libpt-plugins-v4l2         1.10.1.dfsg-1              Portable Windows Library Video Plugin for Video4Linux v2

> Seem to be two differents things to me, the massive stat()ing is a bug, the
> missing "Codec" (?) is an installation issue. 1. might disappear when plugins
> are installed.  

Well I installed all the debian packages I could find. It could be a problem
with the debian package build.

I don't know what the massive stating thing is but I imagined it was searching
for audio codecs. Perhaps it's separate though.
-------------------------------

It's indeed searching for plugins (any kind, codecs, audio drivers and video drivers), but the behaviour is bogous. Anyways.

Check if the debian builds come with the codec plugins bein in some libopal-* package.

what do they look like

The files are named *_pwplugin.so, but I only wondered if the debian opal packages ship the plugins separately.

stark:/home/stark/src/pgsql-sn# locate pwplugin.so
/usr/lib/debug/usr/lib/pwlib/codecs/audio/g726_audio_pwplugin.so
/usr/lib/debug/usr/lib/pwlib/codecs/audio/gsm0610_audio_pwplugin.so
/usr/lib/debug/usr/lib/pwlib/codecs/audio/gsmamrcodec_pwplugin.so
/usr/lib/debug/usr/lib/pwlib/codecs/audio/ilbc_audio_pwplugin.so
/usr/lib/debug/usr/lib/pwlib/codecs/audio/ima_adpcm_audio_pwplugin.so
/usr/lib/debug/usr/lib/pwlib/codecs/audio/lpc10_audio_pwplugin.so
/usr/lib/debug/usr/lib/pwlib/codecs/audio/speex_audio_pwplugin.so
/usr/lib/debug/usr/lib/pwlib/codecs/video/h261-vic_video_pwplugin.so
/usr/lib/pwlib/codecs/audio/g726_audio_pwplugin.so
/usr/lib/pwlib/codecs/audio/gsm0610_audio_pwplugin.so
/usr/lib/pwlib/codecs/audio/gsmamrcodec_pwplugin.so
/usr/lib/pwlib/codecs/audio/ilbc_audio_pwplugin.so
/usr/lib/pwlib/codecs/audio/ima_adpcm_audio_pwplugin.so
/usr/lib/pwlib/codecs/audio/lpc10_audio_pwplugin.so
/usr/lib/pwlib/codecs/audio/speex_audio_pwplugin.so
/usr/lib/pwlib/codecs/video/h261-vic_video_pwplugin.so
/usr/lib/pwlib-cvs/device/sound/alsa_pwplugin.so
/usr/lib/pwlib-cvs/device/sound/oss_pwplugin.so
/usr/lib/pwlib-cvs/device/videoinput/avc_pwplugin.so
/usr/lib/pwlib-cvs/device/videoinput/dc_pwplugin.so
/usr/lib/pwlib-cvs/device/videoinput/v4l2_pwplugin.so
/usr/lib/pwlib-cvs/device/videoinput/v4l_pwplugin.so
/usr/lib/pwlib/device/sound/alsa_pwplugin.so
/usr/lib/pwlib/device/sound/oss_pwplugin.so
/usr/lib/pwlib/device/videoinput/avc_pwplugin.so
/usr/lib/pwlib/device/videoinput/v4l2_pwplugin.so
/usr/lib/pwlib/device/videoinput/v4l_pwplugin.so

I don't know off from my head if that gives trouble, but could it be that all audio codecs are disabled in Preferences->....->Audio Codecs?

(Sorry, can't look myself).

well neither can I...


Man, how I hate bugzilla.

Well, in fact the problem with searching the plugins like crazy was discussed
on the -devel- mailing-list, not here. It's fixed in cvs :
 * $Log: pluginmgr.cxx,v $
 * Revision 1.32  2006/09/11 08:45:32  csoutheren
 * Simplify search path for plugins

What's the CVS repository? I've searched the web site repeatedly and the only references I can find to the CVS version just point me to snapshots that are never up to date. It's nice that you make snapshots but I would still like to try building from CVS.

Search on cvs.gnome.org for the ekiga module, and you should find the cvs :-)

Anyway, you reported two issues :
(1) recursive search in home directory ;
(2) not found plugin codecs.

Issue (1) is fixed in cvs, issue (2) is probably an installation issue.

I close this as OBSOLETE, but beware that when you test HEAD, you should both be prepared for a hard ride, and to use the -devel- mailing-list to report success or problems.

I don't understand what you mean by "installation issue". I mean, of course it's an installation issue but that doesn't mean it's not a bug. I installed the Debian packages and they didn't work. Is there some other place to report problems with the Debian packages? I downloaded them from your repository so I assumed it was the same bug tracking system.

Also, do you really close bugs as soon as they're fixed in CVS? Before the next release? Then how is a user supposed to check if the bug he's reporting is a known issue? Don't you get the same bugs reported over and over again then?

Notice you use -cvs packages, which as their name states, are very unstable snapshots of the developpement, not released versions.

So yes, -cvs packages have bugs, and we don't want to see those in the bugzilla but on the mailing-list.

Read changelog.Debian.gz in those packages.

Sorry to be harsh, but you really seem to believe you got something stable, while the name of the packages themselves point to the contrary.

No, really I'm not confused. I expect there to be bugs. I even went through the trouble of registering on your bugzilla and going through this awful web interface to do you the service of reporting them. I'm not clear why you aren't interested in fixing them. I mean, what's the point of building packages if your not interested in hearing when they're broken?

I would be much happier reporting them to the mailing list actually, I really hate  having to go through bugzilla's awful web interface. But I do wonder why bother using it if you want bug reports on the mailing list.

I actually would much rather be using the actual CVS rather than out of date snapshots but your web site seems to go out of its way to avoid mentioning the CVS repository. There's no search on cvs.gnome.org and while I'm sure I could find it if I spent a while looking around I'm really unclear why you're playing these games. Do you want people running weeks old snapshots repeatedly reporting the same old bugs you've already fixed?

We want the bug reports on the mailing-list, because the cvs has very volatile bugs. If you were using released version packages, the bugzilla would be a good place to ask. It can also be used to request for an enhancement.

The point isn't that we're not interested in fixing the bugs -- the point is that since you don't follow the -devel- list, you have reported something we already knew. As proof, we were already discussing your point (1) since some hours on the mailing-list, and were coming to a solution, which will also handle your point (2)...

Remember : cvs may work at 14:12, be broken at 14:17 and work again at 14:20 ; so the report should be as real-time as possible, and for this the graduation of report is : irc -> devel ml -> bugzilla.

For the outdated cvs snapshots : we stopped them a few months ago because of big changes we didn't want to track in opal's cvs. We'll restart them now we're getting our HEAD in sync with opal and pwlib's.