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.
Created attachment 35819 [details] museseq-0.7.0 ebuild
Please re-attach the ebuild as a text file.
Created attachment 36025 [details] museseq-0.7.0.ebuild Reattached 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 attachment 36681 [details] error when emergeing I get this error in the last stage of the ebuild... I can confirm it definitely did not place the binary into /usr/local/bin
Created attachment 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.
Comment on attachment 36846 [details] alternate /usr/local/portage/media-sound/museseq/museseq-0.7.0.ebuild obsoleting the alternate ebuild, focusing on existing one.
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 attachment 40336 [details, diff] 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 attachment 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"
Created attachment 40338 [details] v2, media-sound/museseq/museseq-0.7.0-r1.ebuild misplaced quote
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).