Bug 57740 - museseq-0.7.0.ebuild
|
Bug#:
57740
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: x86
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: enhancement
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: chriswhite@gentoo.org
|
Reported By: ian_at_school@hotmail.com
|
|
Component: Ebuilds
|
|
|
URL:
|
|
Summary: museseq-0.7.0.ebuild
|
|
Keywords:
|
|
Status Whiteboard: ebuild check
|
|
Opened: 2004-07-20 08:40 0000
|
New Version of Muse(seq) is out. 0.7.0
I've written an ebuild for it. I modified the previous version's ebuild.
This is my first time emerging any version of Museseq, and there were some issues:
i had to emerge fluidsynth first, I tried without, and it wouldnt compile.
i had to copy /usr/local/portage/media-sound/museseq-0.7.0/image/usr/bin/muse to /usr/bin Because a script was looking for it and my emerge died while trying to chmod it.
Reproducible: Always
Steps to Reproduce:
1.
2.
3.
Please re-attach the ebuild as a text file.
will check this when I get back from work.
I can't get any MIDI out of Muse after opening up a midi file that plays fine
in RoseGarden.
Also within a minute a dialog box pops up indicating that Muse has disconnected
from JACK, usually preceded by at least 5 entries like this in the qjackctl
Messages window:
subgraph starting at qjackctl-8813 timed out (subgraph_wait_fd=19, status = 0,
state = Finished)
**** alsa_pcm: xrun of at least 0.761 msecs
20:00:47.543 XRUN callback. (23)
Nothing else causes immense amounts of XRUNs on my machine and when one
normally occurs it doesn't have the line about the "subgraph starting...".
Created an attachment (id=36846) [details]
alternate /usr/local/portage/media-sound/museseq/museseq-0.7.0.ebuild
works for me, shamelessly stolen from earlier museseq ebuild and modified.
there's some bugs to work out before we get this committed to portage, guys.
This error was caused by the Xeconf you had (instead of econf)
--disable-suid-build, which was part of myconf is supposed to
prevent this from even being hit, but since econf was never run (since
the command Xeconf would not be found), this little section wasn't run.
Once I finalize the compile, I'll bump to cvs.
My mistake, one of the devs notified me of Xeconf for virtualx eclass.
I'm going to try it with plain configure to make sure then.
This suid stuff isn't supposed to be hit :|.
Alright, the actual program compiles now (after adjusting a couple of things),
but the runtime fails. This is due to a missing /dev/rtc, which the lack of
appears to cause a nice segfault with museseq. I'm discussing with other
devs what would happen as far as adding an rtc group for us to utilize in
situations like this, where rtc access is required.
even as root this sucker refuses to access /dev/rtc
what's going on?
can you get museseq to work with the new optional support for vst plugins
(./configure --with-vst) ??? it will additionally require an ebuild for libfst
to be written in order to get it to work. if vst plugin support was available
in this ebuild it would open a whole new world to me. i would appreciate it
tremendously. if you decide to do it, just let me know if you need anything.
you can get libfst here:
http://linuxaudiosystems.com/fst/
I have the same problem with /dev/rtc. maybe it has to do with using udev as
apposed to devfs. (just a thought, i hope that isn't it) I have the problem
with both muse 0.6.3 and 0.7.0. It has nothing to do with permissions because i
ran it has root and it still could not access /dev/rtc it gives and ioctl error
message when attempting to set the tick rate. It sates that it is an invalid
ioctl interface for the device. Perhaps muse is used a deprecated api to
communicate with the realtime clock. Perhaps something in this api is broken in
gentoo-dev-sources-2.6.8 (the kernel i use). Could the other persons
encountering this problem please elaborate on the environment in which in
occurs ie kernel version and udev or devfs.
Also i have this to add:
I have started working on getting libfst to function in gentoo and the VSTi support in muse to work, but the /dev/rtc thing is blocking my progress. So until that is figured out i am not concerned with the VSTi support anymore.
It complains during the install process that /usr/bin/muse doesn't exist. If
you create a blank file there beforehand, it installs okay. Simple to fix. It
run okay too. I created a script to start jackd and ladccad first and then shut
them down afterwards. All this still needs to be run as root so I use sudo on
the script.
...
if test "yes" = "yes"; then \
su -c "chown root /usr/bin/muse; chmod +s /usr/bin/muse"; \
fi
chown: cannot access `/usr/bin/muse': No such file or directory
chmod: cannot access `/usr/bin/muse': No such file or directory
...
need to fix this.
update. hacked on the ebuild, wrote it over from scratch, new errors to
contend with. will deal with tomorrow (need some sleep right now). is it
okay that we use the 'sdk' USE flag from x11 for the "FreeST" dep? ask the
x11 crew.
update. spyderous okay'ed the use of 'sdk' USE flag. re-did MusE Sequencer
0.7.0-r1 ebuild from scratch, need to talk to x11 guys some more and ask about
fixing up WINE (the winelib path needs to be added to /etc/env.d/*)
guess the wine library path issue is a very old (circa 2002) bug. marking bug
#9842 as a blocker of the MusE Sequencer 0.7.0 version bump.
Created an attachment (id=40336) [details]
v1, 00_configure_remove_suidinstall.patch
modifies 2 lines in configure and confiugre.ac each, to comment out / correct
some logic used when installing suid ${prefix}/muse binary. fixes the case
where the install script looks for /usr/bin/muse and cannot find it.
Created an attachment (id=40337) [details]
v1, media-sound/museseq/museseq-0.7.0-r1.ebuild
obsoletes http://bugs.gentoo.org/attachment.cgi?id=36025
updates for ebuild ChangeLog (muse 0.7.0-r1) by Eric Shattow
- cleanup; credits go in the ChangeLog
- gcc3.4.x detection (disabled for now)
- rename muse binary to museseq; avoids conflict with media-sound/muse
- add doc, debug, sdk (FreeST) USE flag handling; sdk disabled for now
- add perl dep (is this necessary?)
- remove jack USE flag; MusE Sequencer 0.7.0+ is now always a jack client
- replaced postinst message with updated notice; old one no longer applies
- 00_configure_remove_suidinstall.patch; fixes "/usr/bin/muse not found"
I'm testing it right now. Couple of things to note though:
#IUSE="fluidsynth doc ladcca sdk debug"
IUSE="fluidsynth doc ladcca debug"
I usually comment things that have inactive USE flags (ie. sdk) so as a note
later on to look it over.
doc? ( app-text/openjade
app-doc/doxygen
media-gfx/graphviz )
You can do this instead of the three doc? lines. Also, you don't need to
worry about using \ for multi-line depends, as python somewhat manages that
gracefully (as is seen in the soon to be ebuild).
COPYING is not a required doc, and is ommited to save space. Mainly because
we make sure we follow COPYING before adding to the tree anyways.
I'll put this up for now, but I'd like to know out of curiousity as to why the
pre-compiled headers and sdk stuff was disabled. If it's not having gcc 3.4
that's an issue, I'll test it on a machine that does have it. Couldn't think
of a reason as far as the sdk though.
Thanks again for posting :).
Chris, thanks for having a look.
The reason for the commented-out gcc34 is a missing "all.h" header, and sdk is out because of some Qt weirdness plus it depends on libfst anyways which isn't in portage yet. Once you get MusE Sequencer 0.7.0 installed it's still a mess, in fact, on my machine it refuses to record/play midi events. The lmuse.sf.net cvs checkout from today of "muse/omuse" is an updated and much more stable/functional version than 0.7.0 release. I'm working on a patch. Given that the 0.7.0 release is fubar, i'm adding libfst as a bug dependency and we can remove that later to make a release if necessary.
Fair enough :). Added to portage.. thanks for reporting :). Bug me later
if once new release material is ready (the stuff you were refering to in cvs).
