Re: [proaudio] bristol: missing file

[Thomas Kuther <gimpel@xxxxxxxxxxxxxxxx>]

On Mi, 09.05.07 21:22 Dominique Michel <dominique.michel@xxxxxxxxxxxx>
wrote:

> > Sorry, but I do not want to have directories like /opt/lib
> > I already tried with prefix=/opt and decided for myself that this
> > sucks. So I tried to get it running in /usr 
> > 
> I know, both ebuilds break gentoo policy. /opt is for binary packages
> and bristol data files must be in /usr/share/bristol.

No, mine just breaks the app completely. Install paths are OK ;)
 
> > And the application does not work anyway, so lets hard mask this
> > ebuild too, and just wait for an usable upstream version that can
> > install its libs to /usr/lib like any other app.
> 
> With my ebuild, it work fine on my system (x86). The new gui is
> terrific.

Hammond simply segfaults here right before bringing up the gui without
any meaningful message.

> > 
> > Also I tried to fix startBristol script, look at the patch.
> > 
> > tom@SiRiUS ~ $ startBristol -jack -hammond
> > /opt/bin/startBristol: line 208: [: too many arguments
> > /opt/bin/startBristol: line 235: [: 128: binary operator expected
> > ldd: /opt/bristol/bin/bristol: Datei oder Verzeichnis nicht gefunden
> > Requested Jack drivers, not compiled into bristol
> > 
> 
> Your command line is wrong. 'startBristol -v -h' is also wrong.
> 
> /startBristol -b3 -audio jack -rate 48000

Hmmmm...

....
opened GUI midi handle: 1, fd 58
Read Configuration: hammondB3
brightonWorldChanged(745 325 10 10)
closedown on interrupt
midi write error, fd 5, size 1
cleared sigpipe handler
cleanupBrighton(0)
midi write error, fd 5, size 1
midi write error, fd 5, size 12
midi write error, fd 5, size 1
return - no data in buffer
socket closed
request acked: -1

And dead it is. Same result as -jack, which was the way it worked on
older version. So next problem here.

> work fine for me with my ebuild. With your ebuild, I get another
> error:
> 
> spawning midi thread
> parent going into idle loop
> midi sequencer
> connected to :0.0
> display is 1600 by 1200 pixels
> Window is w 1600, h 1200, d 24, 0 0 0
> Using DirectColor display
> Initialise the hammondB3 link to bristol: 8103848
> Opened listening control socket: 5028
> Client ID = 129
> Queue ID = 0
> Registering 0 1
> Registered 129 0
> Device name "bristol"did not parse, defaults 128.0
> hostname is localhost, bristol
> port is 5028
> Connected to the bristol control socket: 4
> Accepted connection from 0 (3) onto 2 (5)
> bristolengine already active
> created 16 voices: allocated 16 to synth
> engine MIDI channel 0
> spawning audio thread
> registering jack interface
> JACK tmpdir identified as [/dev/shm]
> initialising one hammond sound
> Failed to open factory cache: /usr/memory/profiles/tonewheel

This is why. That file is in /usr/share/bristol/memory, --prefix does
not work right it seems ;)

> [...]
> Bristol's autotools is broken, not the program. --prefix is working,
> but not the configure options for the other paths (--exec-prefix, and
> so on).

See above.

> I just get it to work with --prefix=/usr. I will look if I can pacth
> startBristol with this syntax issue so at 'startBristol -v -h' give
> us the right syntax to use.
> 
> I will commit the ebuild later. It just patch configure.ac and
> Makefile.am and do an eautoreconf before configure. So, no need to
> modify the program files.

That would be cool. Maybe mail those patches to Nick then.
prefix=/usr results in /usr/bristol here. Not accepatable.
Also /opt/lib is not acceptable.

With my ebuild all stuff is in /usr/share/bristol as it should be, but
somehow it breaks startBristol, and I do not have more time to
investigate at the moment.
Same problems in the spec file of packman for openSUSE, install paths
are OK, but startup script is broken.. 

Regards,
Tom

Attachment: signature.asc
Description: PGP signature