Realplay broken?

[Patrick O'Callaghan]

Realplay gives me this error when I try to run a clip:

Opening ALSA PCM device default
        Opening ALSA PCM device default
        The program 'realplay.bin' received an X Window System error.
        This probably reflects a bug in the program.
        The error was 'BadMatch (invalid parameter attributes)'.
          (Details: serial 56 error_code 8 request_code 140 minor_code 13)
          (Note to programmers: normally, X errors are reported asynchronously;
           that is, you will receive the error a while after causing it.
           To debug your program, run it with the --sync command line
           option to change this behavior. You can then get a meaningful
           backtrace from your debugger if you break on the gdk_x_error() function.)

I'm on x64_86 but have also installed gtk2-engines.i386 and
alsa-plugins-pulseaudio.i386. Anything else I might be missing?

poc

[Mauriat M]

On Sat, May 10, 2008 at 3:31 PM, Patrick O'Callaghan  wrote:
> Realplay gives me this error when I try to run a clip:
>     Opening ALSA PCM device default
>     Opening ALSA PCM device default
>     The program 'realplay.bin' received an X Window System error.
>     This probably reflects a bug in the program.
>     The error was 'BadMatch (invalid parameter attributes)'.
>       (Details: serial 56 error_code 8 request_code 140 minor_code 13)
>       (Note to programmers: normally, X errors are reported asynchronously;
>        that is, you will receive the error a while after causing it.
>        To debug your program, run it with the --sync command line
>        option to change this behavior. You can then get a meaningful
>        backtrace from your debugger if you break on the gdk_x_error() function.)
>
> I'm on x64_86 but have also installed gtk2-engines.i386 and
>  alsa-plugins-pulseaudio.i386. Anything else I might be missing?

I gave up with the dependancies in the 32-bit version. I tried a
64-bit build and it worked fine.
http://forms.helixcommunity.org/helix/builds/?category=realplay-current

-Mauriat

[Patrick O'Callaghan]

On Mon, 2008-05-12 at 09:06 -0400, Mauriat M wrote:
> On Sat, May 10, 2008 at 3:31 PM, Patrick O'Callaghan  wrote:
> > Realplay gives me this error when I try to run a clip:
> >     Opening ALSA PCM device default
> >     Opening ALSA PCM device default
> >     The program 'realplay.bin' received an X Window System error.
> >     This probably reflects a bug in the program.
> >     The error was 'BadMatch (invalid parameter attributes)'.
> >       (Details: serial 56 error_code 8 request_code 140 minor_code 13)
> >       (Note to programmers: normally, X errors are reported asynchronously;
> >        that is, you will receive the error a while after causing it.
> >        To debug your program, run it with the --sync command line
> >        option to change this behavior. You can then get a meaningful
> >        backtrace from your debugger if you break on the gdk_x_error() function.)
> >
> > I'm on x64_86 but have also installed gtk2-engines.i386 and
> >  alsa-plugins-pulseaudio.i386. Anything else I might be missing?
>
> I gave up with the dependancies in the 32-bit version. I tried a
> 64-bit build and it worked fine.
> http://forms.helixcommunity.org/helix/builds/?category=realplay-current

I tried that, but got "error while loading shared libraries: libstdc
++.so.5: cannot open shared object file: No such file or directory".

I have libstdc++-4.3.0-8.x86_64, which includes /usr/lib64/libstdc
++.so.6. Is there some other package I should install to
get /usr/lib64/libstdc++.so.5?

poc

[Mauriat M]

On Mon, May 12, 2008 at 11:28 AM, Patrick O'Callaghan
 wrote:
> On Mon, 2008-05-12 at 09:06 -0400, Mauriat M wrote:
> > On Sat, May 10, 2008 at 3:31 PM, Patrick O'Callaghan  wrote:
> > > Realplay gives me this error when I try to run a clip:
> > >     Opening ALSA PCM device default
> > >     Opening ALSA PCM device default
> > >     The program 'realplay.bin' received an X Window System error.
> > >     This probably reflects a bug in the program.
> > >     The error was 'BadMatch (invalid parameter attributes)'.
> > >       (Details: serial 56 error_code 8 request_code 140 minor_code 13)
> > >       (Note to programmers: normally, X errors are reported asynchronously;
> > >        that is, you will receive the error a while after causing it.
> > >        To debug your program, run it with the --sync command line
> > >        option to change this behavior. You can then get a meaningful
> > >        backtrace from your debugger if you break on the gdk_x_error() function.)
> > >
> > > I'm on x64_86 but have also installed gtk2-engines.i386 and
> > >  alsa-plugins-pulseaudio.i386. Anything else I might be missing?
> >
> > I gave up with the dependancies in the 32-bit version. I tried a
> > 64-bit build and it worked fine.
> > http://forms.helixcommunity.org/helix/builds/?category=realplay-current
>
> I tried that, but got "error while loading shared libraries: libstdc
>  ++.so.5: cannot open shared object file: No such file or directory".
>
> I have libstdc++-4.3.0-8.x86_64, which includes /usr/lib64/libstdc
>  ++.so.6. Is there some other package I should install to
>  get /usr/lib64/libstdc++.so.5?

I had to do the following.

# yum install libstdc++-33

-Mauriat

[Patrick O'Callaghan]

On Mon, 2008-05-12 at 11:33 -0400, Mauriat M wrote:
> On Mon, May 12, 2008 at 11:28 AM, Patrick O'Callaghan
>  wrote:
> > On Mon, 2008-05-12 at 09:06 -0400, Mauriat M wrote:
> > > On Sat, May 10, 2008 at 3:31 PM, Patrick O'Callaghan  wrote:
> > > > Realplay gives me this error when I try to run a clip:
> > > >     Opening ALSA PCM device default
> > > >     Opening ALSA PCM device default
> > > >     The program 'realplay.bin' received an X Window System error.
> > > >     This probably reflects a bug in the program.
> > > >     The error was 'BadMatch (invalid parameter attributes)'.
> > > >       (Details: serial 56 error_code 8 request_code 140 minor_code 13)
> > > >       (Note to programmers: normally, X errors are reported asynchronously;
> > > >        that is, you will receive the error a while after causing it.
> > > >        To debug your program, run it with the --sync command line
> > > >        option to change this behavior. You can then get a meaningful
> > > >        backtrace from your debugger if you break on the gdk_x_error() function.)
> > > >
> > > > I'm on x64_86 but have also installed gtk2-engines.i386 and
> > > >  alsa-plugins-pulseaudio.i386. Anything else I might be missing?
> > >
> > > I gave up with the dependancies in the 32-bit version. I tried a
> > > 64-bit build and it worked fine.
> > > http://forms.helixcommunity.org/helix/builds/?category=realplay-current
> >
> > I tried that, but got "error while loading shared libraries: libstdc
> >  ++.so.5: cannot open shared object file: No such file or directory".
> >
> > I have libstdc++-4.3.0-8.x86_64, which includes /usr/lib64/libstdc
> >  ++.so.6. Is there some other package I should install to
> >  get /usr/lib64/libstdc++.so.5?
>
> I had to do the following.
>
> # yum install libstdc++-33

What repo is that in? Yum can't find it.

poc

[Mauriat M]

On Mon, May 12, 2008 at 11:54 AM, Patrick O'Callaghan
 wrote:
> On Mon, 2008-05-12 at 11:33 -0400, Mauriat M wrote:
> > On Mon, May 12, 2008 at 11:28 AM, Patrick O'Callaghan
> >  wrote:
> > > On Mon, 2008-05-12 at 09:06 -0400, Mauriat M wrote:
> > > > On Sat, May 10, 2008 at 3:31 PM, Patrick O'Callaghan  wrote:
> > > > > Realplay gives me this error when I try to run a clip:
> > > > >     Opening ALSA PCM device default
> > > > >     Opening ALSA PCM device default
> > > > >     The program 'realplay.bin' received an X Window System error.
> > > > >     This probably reflects a bug in the program.
> > > > >     The error was 'BadMatch (invalid parameter attributes)'.
> > > > >       (Details: serial 56 error_code 8 request_code 140 minor_code 13)
> > > > >       (Note to programmers: normally, X errors are reported asynchronously;
> > > > >        that is, you will receive the error a while after causing it.
> > > > >        To debug your program, run it with the --sync command line
> > > > >        option to change this behavior. You can then get a meaningful
> > > > >        backtrace from your debugger if you break on the gdk_x_error() function.)
> > > > >
> > > > > I'm on x64_86 but have also installed gtk2-engines.i386 and
> > > > >  alsa-plugins-pulseaudio.i386. Anything else I might be missing?
> > > >
> > > > I gave up with the dependancies in the 32-bit version. I tried a
> > > > 64-bit build and it worked fine.
> > > > http://forms.helixcommunity.org/helix/builds/?category=realplay-current
> > >
> > > I tried that, but got "error while loading shared libraries: libstdc
> > >  ++.so.5: cannot open shared object file: No such file or directory".
> > >
> > > I have libstdc++-4.3.0-8.x86_64, which includes /usr/lib64/libstdc
> > >  ++.so.6. Is there some other package I should install to
> > >  get /usr/lib64/libstdc++.so.5?
> >
> > I had to do the following.
> >
> > # yum install libstdc++-33
>
> What repo is that in? Yum can't find it.

Sorry compat-libstdc++-33

-Mauriat

[Bill Crawford]

2008/5/12 Patrick O'Callaghan :
> On Mon, 2008-05-12 at 11:33 -0400, Mauriat M wrote:
> > # yum install libstdc++-33
> What repo is that in? Yum can't find it.

It's a little bit late for this, but yum also copes with "yum install
libstdc++.so.5"

[Mauriat M]

On Mon, May 12, 2008 at 12:02 PM, Bill Crawford
 wrote:
> 2008/5/12 Patrick O'Callaghan :
> > On Mon, 2008-05-12 at 11:33 -0400, Mauriat M wrote:
> > > # yum install libstdc++-33
> > What repo is that in? Yum can't find it.
>
> It's a little bit late for this, but yum also copes with "yum install
>  libstdc++.so.5"

I assumed the op knew that, but my mistake.

-Mauriat

[Bill Crawford]

2008/5/12 Mauriat M :
> I assumed the op knew that, but my mistake.

No criticism intended! I had to go check it did really work before I replied ;o)

[Patrick O'Callaghan]

On Mon, 2008-05-12 at 12:08 -0400, Mauriat M wrote:
> On Mon, May 12, 2008 at 12:02 PM, Bill Crawford
>  wrote:
> > 2008/5/12 Patrick O'Callaghan :
> > > On Mon, 2008-05-12 at 11:33 -0400, Mauriat M wrote:
> > > > # yum install libstdc++-33
> > > What repo is that in? Yum can't find it.
> >
> > It's a little bit late for this, but yum also copes with "yum install
> >  libstdc++.so.5"
>
> I assumed the op knew that, but my mistake.

Methinks thou dost assume too much. The OP didn't actually know that,
despite years of using yum. The man page gives the yum syntax as "yum
install [package ...]" and says nothing at all about "yum install
[feature ...]".

It turns out that "yum install feature" installs the i386 version, but
it was enough to reconstruct the actual package name.

Anyway, it installed OK, so thanks everyone.

poc

[Mauriat M]

On Mon, May 12, 2008 at 12:24 PM, Patrick O'Callaghan
 wrote:
> Methinks thou dost assume too much. The OP didn't actually know that,
>  despite years of using yum. The man page gives the yum syntax as "yum
>  install [package ...]" and says nothing at all about "yum install
>  [feature ...]".

Since you mentioned the man pages, I think 'yum whatprovides' is
listed there which could be used to determine the package to install.

-Mauriat

[Patrick O'Callaghan]

On Mon, 2008-05-12 at 12:40 -0400, Mauriat M wrote:
> On Mon, May 12, 2008 at 12:24 PM, Patrick O'Callaghan
>  wrote:
> > Methinks thou dost assume too much. The OP didn't actually know that,
> >  despite years of using yum. The man page gives the yum syntax as "yum
> >  install [package ...]" and says nothing at all about "yum install
> >  [feature ...]".
>
> Since you mentioned the man pages, I think 'yum whatprovides' is
> listed there which could be used to determine the package to install.

Yes I know. Also repoquery can do it. My point is that there is no
indication in the man page that you can use yum this way, even though it
does work (it's what I ended up using just to be sure).

poc

[potat0]

i have a really stupid question here since i hadnt used linux in 10 years but after just dealing with Fedora 9 and some apps that wanted  libstdc++.so.5   
i came across this and another useful link
i got the rpm and had to force it using the following
rpm -ivh --force compat-libstdc++-33-3.2.3-63.x86_64.rpm

then i checked with
rpm -qi compat-libstdc++-33
and it came back with appropriate info

and my app ran

BUT my question is - where did it install libstdc++.so.5?? locate and some other commands fail to find it in any dir

actually then i have more questions
in the future how can i force a directory??? - i really want that lib in  usr/lib    but the only useful info i found in rpm help was about old file path and new file path 
but a lot of time i just want one lib out of some repository

c++ya,
thx in advance
x

[Patrick O'Callaghan]

On Thu, 2008-05-22 at 10:51 +0200, xkey wrote:
> i have a really stupid question here since i hadnt used linux in 10 years but after just dealing with Fedora 9 and some apps that wanted  libstdc++.so.5   
> i came across this and another useful link
> i got the rpm and had to force it using the following
> rpm -ivh --force compat-libstdc++-33-3.2.3-63.x86_64.rpm

Why did you have to force it? It installed for me without forcing.
> then i checked with
> rpm -qi compat-libstdc++-33
> and it came back with appropriate info
>
> and my app ran
>
> BUT my question is - where did it install libstdc++.so.5?? locate and some other commands fail to find it in any dir

rpm -ql compat-libstdc++-33|grep libstdc++.so.5

On my system it's in /usr/lib and /usr/lib64.
> actually then i have more questions
> in the future how can i force a directory??? - i really want that lib in  usr/lib    but the only useful info i found in rpm help was about old file path and new file path 
> but a lot of time i just want one lib out of some repository

Install it and then move it or use a symlink, but don't expect it to
work. If the package wants it in a specific place it's usually for a
good reason. Package installation doesn't just plonk a file somewhere,
it runs scripts and updates a database. Moving stuff around (even if it
works) is likely to screw up any future updates, so you're losing most
of the advantages of using a package system in the first place.

poc

[Matej Cepl]

On 2008-05-22, 08:51 GMT, xkey wrote:
> i have a really stupid question here since i hadnt used linux 
> in 10 years but after just dealing with Fedora 9 and some apps 
> that wanted  libstdc++.so.5   
> i came across this and another useful link
> i got the rpm and had to force it using the following
> rpm -ivh --force compat-libstdc++-33-3.2.3-63.x86_64.rpm

While you were out of the Linux world yum happened so now you can 
do

yum install 'libstdc++.so.5()(64bit)'

or

yum install /usr/lib64/libstdc++.so.5

and it will install appropriate package for you (of course, in 
the second case you have to know where the file goes). The string 
in the first case is what is required by the package you want to 
install (rpm -qRp package*.x86_64.rpm will tell you it).

Best,

Matěj

[Neal Becker]

Mauriat M wrote:
> On Sat, May 10, 2008 at 3:31 PM, Patrick O'Callaghan  wrote:
> > Realplay gives me this error when I try to run a clip:
> >     Opening ALSA PCM device default
> >     Opening ALSA PCM device default
> >     The program 'realplay.bin' received an X Window System error.
> >     This probably reflects a bug in the program.
> >     The error was 'BadMatch (invalid parameter attributes)'.
> >       (Details: serial 56 error_code 8 request_code 140 minor_code
> >       13) (Note to programmers: normally, X errors are reported
> >       asynchronously;
> >        that is, you will receive the error a while after causing it.
> >        To debug your program, run it with the --sync command line
> >        option to change this behavior. You can then get a meaningful
> >        backtrace from your debugger if you break on the gdk_x_error()
> >        function.)
> >
> > I'm on x64_86 but have also installed gtk2-engines.i386 and
> >  alsa-plugins-pulseaudio.i386. Anything else I might be missing?
>
> I gave up with the dependancies in the 32-bit version. I tried a
> 64-bit build and it worked fine.
> http://forms.helixcommunity.org/helix/builds/?category=realplay-current

Hey, that's great!  I installed the 64-bit realplay.

One issue, it mistakenly installed plugins into /usr/lib/mozilla/plugins
instead of /usr/lib64.

I tried to report this bug on their site, but I can't seem to get it to
allow me to report a bug.  What's wrong with these people?

[Mauriat M]

On Mon, May 12, 2008 at 10:05 PM, Neal Becker  wrote:
> Mauriat M wrote:
> > On Sat, May 10, 2008 at 3:31 PM, Patrick O'Callaghan  wrote:
> > > Realplay gives me this error when I try to run a clip:
> > >     Opening ALSA PCM device default
> > >     Opening ALSA PCM device default
> > >     The program 'realplay.bin' received an X Window System error.
> > >     This probably reflects a bug in the program.
> > >     The error was 'BadMatch (invalid parameter attributes)'.
> > >       (Details: serial 56 error_code 8 request_code 140 minor_code
> > >       13) (Note to programmers: normally, X errors are reported
> > >       asynchronously;
> > >        that is, you will receive the error a while after causing it.
> > >        To debug your program, run it with the --sync command line
> > >        option to change this behavior. You can then get a meaningful
> > >        backtrace from your debugger if you break on the gdk_x_error()
> > >        function.)
> > >
> > > I'm on x64_86 but have also installed gtk2-engines.i386 and
> > >  alsa-plugins-pulseaudio.i386. Anything else I might be missing?
> >
> > I gave up with the dependancies in the 32-bit version. I tried a
> > 64-bit build and it worked fine.
> > http://forms.helixcommunity.org/helix/builds/?category=realplay-current
>
> Hey, that's great!  I installed the 64-bit realplay.
>
> One issue, it mistakenly installed plugins into /usr/lib/mozilla/plugins
>  instead of /usr/lib64.
>
> I tried to report this bug on their site, but I can't seem to get it to
>  allow me to report a bug.  What's wrong with these people?

Well I would guess these are technically "unsupported" build.
Did you try the forums?

-Mauriat