"LMMS aims to be a free alternative to popular (but commercial and closed- source) programs like FruityLoops, Cubase and Logic giving you the ability of producing music with your computer by creating/synthesizing sounds, arranging samples, playing live with keyboard and much more... LMMS combines the features of a tracker-/sequencer-program (pattern-/channel-/ sample-/song-/effect-management) and those of powerful synthesizers and samplers in a modern, user-friendly and easy to use graphical user-interface." That app is going to rock! Still a bit cpu hungry, but already good usable and worth testing. I think that needs an ebuild Reproducible: Always Steps to Reproduce:
Created attachment 64223 [details] media-sound/lmms-0.1.0_rc1.ebuild
Please fix the following and reopen: * You can use versionator.eclass to do the version manipulation. * Any reason hqsinc is a USE flag? Why not just always enable it? * ${WORKDIR}, ${S}, ${D}, ${A} need quoting. * No need to dodoc COPYING.
Created attachment 68385 [details] lmms-0.1.0_rc1.ebuild changed and slightly cleaned ebuild
can someone, please, reopen this so that i wont post a new bug ....
Looks good to me.
Created attachment 68387 [details] lmms-0.1.0_rc1.ebuild forgot to remove hqsinc from IUSE
1.should "die" be added to dodoc? 2.should libsdl be listed as a dependacy when it is a dependancy for sdl-sound?
regarding the README, SDL-sound isn't optional, but libsdl is for sdl support (don't ask me, i didn't get it too :P) so the DEPEND settings in first ebuild where correct (if one believes the readme file) sorry for not fixing and reopening that bug myself - wanted to wait for new release from tobi which will have lots of fixes and enhancements, but that seems to take longer.
Created attachment 68391 [details] lmms-0.1.0_rc1.ebuild fixed "--enable-hqsinc" quoting added die to dodoc sdl sound IS optional... i've just tested lmms with sdl-sound being removed from my system well ... it can be compiled with support for sdl and/or sdl-sound ... (sdl for output and sdl-sound for loading samples) and so i have another question -should sdlsound be separate dependancy controlled by separate USEflag?
"(sdl for output and sdl-sound for loading samples)" that's the point! what's a sample sequencer w/o being able to load samples...nothing. so strange it compiles without it, isn't it? but the output - well you want alsa, or sdl? (or jack in the future release - i'm getting impatient :)) - that's optional.
without sld-sound it loads with libsndfile and libvorbis
This ebuild doesn't seem to be imported in portage yet. Why is that so ?
(In reply to comment #12) > This ebuild doesn't seem to be imported in portage yet. Why is that so ? Because no developer commited it yet. There are hundreds of ebuilds waiting for inclusion, so please don't clutter the bug with such comments, it's pointless. Thanks.
Created attachment 70442 [details] lmms-0.1.1.ebuild version bump. now with jack support ;)
is S=${WORKDIR}/${P} really needed?
*** Bug 117793 has been marked as a duplicate of this bug. ***
Shouldn't the USE flag for libsamplerate be "libsamplerate" instead of "samplerate"? A 'grep "samplerate" $PORTDIR/profiles/use.*' only finds "libsamplerate".
Can someone create an ebuild for 0.1.2? Also it would be great if this would be put in the official portage tree. Thanks
Ok, it builds and runs fine, but plugins only work after /usr/lib/lmms/ is added to /etc/ld.so.conf (and ldconfig is executed), or after setting LD_LIBRARY_PATH=/usr/lib/lmms. I wonder what's the usual solution for packages which show similar behavior? The latest ebuild in this bug works nicely after renaming it to lmms-0.1.2.ebuild. However, there is an unnecessary S= line in it. ${WORKDIR}/${P} is the default value of ${S}.
(In reply to comment #19) > Ok, it builds and runs fine, but plugins only work after /usr/lib/lmms/ is > added to /etc/ld.so.conf (and ldconfig is executed), or after setting > LD_LIBRARY_PATH=/usr/lib/lmms. > > I wonder what's the usual solution for packages which show similar behavior? Yeah, seems to be a problem with that version. Also affects rpm'e for SuSE found on packman. Fixed in CVS already (Anyone here wants the CVS ebuild i use?) > The latest ebuild in this bug works nicely after renaming it to > lmms-0.1.2.ebuild. However, there is an unnecessary S= line in it. > ${WORKDIR}/${P} is the default value of ${S}. > Sorry, right, it's not needed. Let's wait for next release and fix all that. Also VST support is up to come.
Created attachment 78349 [details] lmms-9999.ebuild Ok added the CVS ebuild (-* masked). Mostly because i'd like to hear an opinion if adding VST support that way is OK. Note that Tobi switched to xfst, which currently does not compile... also Steinberg provides vstsdk-2.4 meanwhile.
The ebuild works just fine for the newest version (0.1.4) after renaming it.
Created attachment 79401 [details] lmms-0.1.4.ebuild
Comment on attachment 79401 [details] lmms-0.1.4.ebuild Added 0.1.4. This is my first ebuild I have worked with so it probly has a bug or two in it, unless it really was as easy as it looked ;-) It works on my ~amd64 system. BTW can someone put this in portage? At least version 0.1.1, it seems to be stable.
- S=${WORKDIR}/${P} is superfluous
(In reply to comment #24) > (From update of attachment 79401 [details] [edit]) > This is my first ebuild Congratulations! > it probly has a bug or two in it You should use the header from /usr/portage/header.txt instead of copying it from another ebuild. For instance, the year on the copyright in the ebuild you attached is 1999-2005, but it is 2006 now and /usr/portage/header.txt reflects that. Thanks for submitting the ebuild and good luck in the future.
Created attachment 90086 [details] Fixed ebuild Ebuild with some fixes. Correct date in header, changed oggvorbis to vorbis, deps versions fixed and changed use_enabled to use_with.
Created attachment 90091 [details] lmms-0.1.4-r1.ebuild Fixed strip and debug stuff.
This is now in the sunrise overlay. You can find it at: http://gentoo-sunrise.org/svn/reviewed/media-sound/lmms/
Created attachment 92239 [details] LMMS 0.2.0 Ebuild
Created attachment 92240 [details] lmms-0.2.0.ebuild Sorry forgot to take out the -j1 option.
Why only ~amd64? Works of course with ~x86, too. Please add the flag.
Created attachment 93690 [details] lmms-0.2.1.ebuild Works fine for 0.2.1 after renaming. Also added ~x86 keyword.
*** Bug 143559 has been marked as a duplicate of this bug. ***
Is it possible to ad VST support to this using the ebuild? The instructions (http://wiki.mindrules.net/doku.php?id=documentation:installation&s=vst#enable_vst_support)say this: 1. Install WINE 2. Get Steinberg's VST SDK (the links on the WIKI are wrong, it is actually at http://ygrabit.steinberg.de/~ygrabit/public_html/index.html), and I think the files are fetch-restricted. That might be a problem. 3. Put the files "AEffect.h" and "aeffectx.h" in the lmms-0.2.1/include/ directory 4. Run the included patch (patch -p0 < ../vst_sdk23_headers.diff) 5. Add "--with-vst" to ./configure I'm pretty sure it's possible to do this with an ebuild... could someone help me do it?
(In reply to comment #35) > 2. Get Steinberg's VST SDK (the links on the WIKI are wrong, it is actually > at http://ygrabit.steinberg.de/~ygrabit/public_html/index.html), and I think > the files are fetch-restricted. That might be a problem. The website says to get version 2.3 of the SDK by the way.
(In reply to comment #35) > 1. Install WINE > 2. Get Steinberg's VST SDK (the links on the WIKI are wrong, it is actually > at http://ygrabit.steinberg.de/~ygrabit/public_html/index.html), and I think > the files are fetch-restricted. That might be a problem. That's the problem. Portage doesn't support using fetch-restricted depending on an USE flag, so I think this should be handled in pkg_fetch() in an evil way. > 3. Put the files "AEffect.h" and "aeffectx.h" in the lmms-0.2.1/include/ > directory > 4. Run the included patch (patch -p0 < ../vst_sdk23_headers.diff) > 5. Add "--with-vst" to ./configure > > I'm pretty sure it's possible to do this with an ebuild... could someone help > me do it? > I'm trying to get it working, if you want to help it would be great if you join #gentoo-sunrise on Freenode or if you add me to Jabber (in that case you can email me). Or if you can write a working ebuild it would be great too ;-)
Created attachment 96479 [details] lmms-0.2.1.ebuild + VST support lmms-0.2.1.ebuild with VST support. It compiles without problems but I haven't tested it. Could someone test if VST support works correctly?
I just got an email from toby, he says that that VST 2.4 also works :)
Created attachment 96502 [details] lmms-0.2.1 + VST 2.4 Support Changed some numbers
Created attachment 96506 [details] lmms-0.2.1.ebuild + VST 2.4 Support
Comment on attachment 96506 [details] lmms-0.2.1.ebuild + VST 2.4 Support Fixed a typo <_<
Created attachment 96512 [details] lmms-0.2.1 + VST 2.4 Support Woah I screwed up big time. It seems that all of the files moved to cp ${WORKDIR}/vstsdk2.4/pluginterfaces/vst2.x/{aeffect.h,aeffectx.h} I should look before I atach things next time <_< There was an unzip statement in the ebuild that was causing trouble, so I removed it. It was unnecessary as Portage handled it already. Plus it was looking in the wrong place for the zipped file. Fixed that. The documentation said to make vst the command is --with-vst, and looking through configure.in confirms this. OK, this is the really really fixed version, no half-assed-ness.
Created attachment 96515 [details] lmms-0.2.1 + VST 2.3 Support i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../include -I../../src/lib -I. -I/usr/X11R6/include -DQT3 -I/usr/qt/3/include -D_REENTRANT -DQT_THREAD_SUPPORT -DPLUGIN_NAME=vestige -O2 -march=pentium3 -pipe -fomit-frame-pointer -floop-optimize2 -fgcse-sm -fgcse-las -ftree-vectorize -ftree-loop-linear -funsafe-loop-optimizations -Wunsafe-loop-optimizations -DSINGLE_SOURCE_COMPILE -I/usr/local/include -MT vestige.lo -MD -MP -MF .deps/vestige.Tpo -c vestige.cpp -o vestige.o >/dev/null 2>&1 if wineg++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../include -I../../src/lib -I. -I/usr/X11R6/include -O2 -march=pentium3 -pipe -fomit-frame-pointer -floop-optimize2 -fgcse-sm -fgcse-las -ftree-vectorize -ftree-loop-linear -funsafe-loop-optimizations -Wunsafe-loop-optimizations -MT lvsl_server.o -MD -MP -MF ".deps/lvsl_server.Tpo" -c -o lvsl_server.o lvsl_server.c; \ then mv -f ".deps/lvsl_server.Tpo" ".deps/lvsl_server.Po"; else rm -f ".deps/lvsl_server.Tpo"; exit 1; fi make[4]: *** No rule to make target `lvsl_server.exe.so', needed by `all-am'. Stop. make[4]: *** Waiting for unfinished jobs.... make[4]: Leaving directory `/var/tmp/portage/lmms-0.2.1/work/lmms-0.2.1/plugins/vestige' make[3]: *** [all] Error 2 make[3]: Leaving directory `/var/tmp/portage/lmms-0.2.1/work/lmms-0.2.1/plugins/vestige' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/lmms-0.2.1/work/lmms-0.2.1/plugins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/lmms-0.2.1/work/lmms-0.2.1' make: *** [all] Error 2 That can't be good... Looks like he was wrong, I'll go e-mail him about this bug. OK people, LMMS doesn't work with VST 2.4 after all. Also I'm uploading a fixed version of that other guy's ebuild. now.
Created attachment 96517 [details] lmms-0.2.1 + VST 2.3 Support Fixed yet another typo... my goodness. Sorry for spamming up all of your inboxes, I'm rushing right now because I have to leave. I fail. :V
Created attachment 96519 [details] lmms-0.2.1.ebuild + VST support The other ebuilds have a big problem: They are fetch restricted and they cannot download the main source of the program (I didn't noticed it because I already had the program downloaded on my /usr/portage/distfiles). In order to solve this in the cleanest way, made an ebuild for the VST SDK headers called vst-headers. This way, we can make lmms depend on media-plugins/vst-headers and forget about evil stuff. It also solves the confusion with licenses. So, this ebuild support the new vst-headers.
Created attachment 96520 [details] vst-headers-2.3.ebuild An ebuild for media-plugins/vst-headers
Created attachment 96521 [details] licenses/Steinberg-VST-SDK-LA Steinberg VST Plug-ins SDK Licensing Agreement. This file should go into licenses/
(In reply to comment #44) > Created an attachment (id=96515) [edit] > lmms-0.2.1 + VST 2.3 Support > > i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../include > -I../../src/lib -I. -I/usr/X11R6/include -DQT3 -I/usr/qt/3/include -D_REENTRANT > -DQT_THREAD_SUPPORT -DPLUGIN_NAME=vestige -O2 -march=pentium3 -pipe > -fomit-frame-pointer -floop-optimize2 -fgcse-sm -fgcse-las -ftree-vectorize > -ftree-loop-linear -funsafe-loop-optimizations -Wunsafe-loop-optimizations > -DSINGLE_SOURCE_COMPILE -I/usr/local/include -MT vestige.lo -MD -MP -MF > .deps/vestige.Tpo -c vestige.cpp -o vestige.o >/dev/null 2>&1 > if wineg++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../include -I../../src/lib -I. > -I/usr/X11R6/include -O2 -march=pentium3 -pipe -fomit-frame-pointer > -floop-optimize2 -fgcse-sm -fgcse-las -ftree-vectorize -ftree-loop-linear > -funsafe-loop-optimizations -Wunsafe-loop-optimizations -MT lvsl_server.o -MD > -MP -MF ".deps/lvsl_server.Tpo" -c -o lvsl_server.o lvsl_server.c; \ > then mv -f ".deps/lvsl_server.Tpo" ".deps/lvsl_server.Po"; else rm -f > ".deps/lvsl_server.Tpo"; exit 1; fi > make[4]: *** No rule to make target `lvsl_server.exe.so', needed by `all-am'. > Stop. > make[4]: *** Waiting for unfinished jobs.... > make[4]: Leaving directory > `/var/tmp/portage/lmms-0.2.1/work/lmms-0.2.1/plugins/vestige' > make[3]: *** [all] Error 2 > make[3]: Leaving directory > `/var/tmp/portage/lmms-0.2.1/work/lmms-0.2.1/plugins/vestige' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory > `/var/tmp/portage/lmms-0.2.1/work/lmms-0.2.1/plugins' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/var/tmp/portage/lmms-0.2.1/work/lmms-0.2.1' > make: *** [all] Error 2 > > That can't be good... Looks like he was wrong, I'll go e-mail him about this > bug. > OK people, LMMS doesn't work with VST 2.4 after all. > > Also I'm uploading a fixed version of that other guy's ebuild. now. > The same thing happened to me when I tried VST 2.3. I e-mailed Toby about it. Maybe now that vst-headers is in its own ebuild it'll work?
Created attachment 96533 [details] vst-headers-2.3.ebuild - now with fixed typos (In reply to comment #47) > Created an attachment (id=96520) [edit] > vst-headers-2.3.ebuild > > An ebuild for media-plugins/vst-headers > you made the path /usr/include in this ebuild, but lmms looks for /usr/include/vst. I fixed it for you, though.
Created attachment 96535 [details] lmms-0.2.1 + VST support (In reply to comment #46) > Created an attachment (id=96519) [edit] > lmms-0.2.1.ebuild + VST support > > The other ebuilds have a big problem: > > They are fetch restricted and they cannot download the main source of the > program (I didn't noticed it because I already had the program downloaded on my > /usr/portage/distfiles). > In order to solve this in the cleanest way, made an ebuild for the VST SDK > headers called vst-headers. This way, we can make lmms depend on > media-plugins/vst-headers and forget about evil stuff. > It also solves the confusion with licenses. > > So, this ebuild support the new vst-headers. > You are the second person to make this mistake: vst support is --with-vst NOT --with-wine. If you read the messages it outputs during configure, you'd have noticed that.
NOTE: IF YOU PLAN ON USING VST SUPPORT, LMMS MUST ME COMPILED WITH MAKEOPTS="-j1" OR IT'LL FAIL From my email: "> I get the same thing with VST 2.3. I found the problem: you must not compile LMMS (or at least not VeSTige-plugin) using make -jX where X > 1, this will fail. Try to use a simple make and everything should went fine ;-) toby"
Can anybody help me make the ebuild force MAKEOPTS="-j1"?
(In reply to comment #53) > Can anybody help me make the ebuild force MAKEOPTS="-j1"? > From devmanual.gentoo.org: "Builds should be tested with various -j settings in MAKEOPTS to ensure that the build parallelises properly. If a package does not parallelise cleanly, it should be patched. If patching really isn't an option, emake -j1 should be used. However, when doing this please remember that you are seriously hurting build times for many non-x86 users in particular. Forcing a -j1 can increase build times from a few minutes to an hour on some MIPS and SPARC systems."
I've just made a SVN ebuild. I was thinking if the official site says one should use svn, we (gentoo) should do it. So, how to / should i attach it here (-9999 already exists)? Thanx!
(In reply to comment #55) > I've just made a SVN ebuild. I was thinking if the official site says one > should use svn, we (gentoo) should do it. So, how to / should i attach it here > (-9999 already exists)? Thanx! You can just attach it with the same name. There's no problem with that. Also, we don't use live SVN ebuilds. I'd rather tar a snapshot of latest SVN, upload it somewhere and do an ebuild for it. Anyway, your -9999 ebuild is welcome.
Created attachment 128612 [details] lmms-9999.ebuild (SVN version)
Comment on attachment 78349 [details] lmms-9999.ebuild Made the old one obsolete. Though -9999 ebuild including vst-headers has been available in pro-audio overlay for quite a while...
New version is available : 2007-11-12: LMMS 0.3.1 released Why not adding lmms, a must have :'(
proaudio people may be interested.
Removed from Sunrise. You may want to check proaudio overlay for an updated version.
Created attachment 162506 [details] lmms-0.4.0_beta1.ebuild Posting 0.4.0_beta ebuild from pro-audio overlay. (Not attempting to fix/add lmms-0.3* now) * uses cmake-utils now * parallel make is unsupported by upstream, and it indeed fails with -j > 1, so force -j1
_beta2 is in the tree now, thanks tom
Created attachment 165939 [details] lmms-0.4.0_rc1 ebuild (Read my comments) Hello. I am a developer for LMMS and am correcting some problems and updating the ebuild for our Release Candidate 1. - We have added optional support for Portaudio. So this includes the useflag for it. - Updated package name for lmms-0.4.0-rc1 file - However, the most important change is the removal of the ladspa useflag. The reason is: LMMS has absolutely NO dependency for ladspa: optional or hard. As you may know LADSPA is actually just a header file called ladspa.h. There are no daemons or shared libraries. LMMS includes its own copy of ladspa.h because LMMS includes a number of non-optional LADSPA plugins with our source distribution. Additionally, these plugins must be installed per-default because a number of included demo-projects require them. Again, LMMS contains NO dependency for ladspa-sdk to be installed. LMMS contains built-in support for LADSPA plugins because it ships with its own ladspa.h. I hope this makes sense.
I can confirm that LMMS 0.4.0 works on x86. It would be nice if you could add least add a ~x86 keyword in the ebuild. But there is one thing I've noticed: VST-Support is not being built: [ebuild U ] media-sound/lmms-0.4.0 [0.4.0_rc2] USE="alsa ogg -debug -fftw -fluidsynth -jack -pulseaudio -sdl -stk (-vst) (-pch%) (-portaudio%)" 10,340 kB Wine is installed and I have set the "vst"-USE flag for lmms.
(In reply to comment #65) > I can confirm that LMMS 0.4.0 works on x86. It would be nice if you could add > least add a ~x86 keyword in the ebuild. > But there is one thing I've noticed: VST-Support is not being built: > [ebuild U ] media-sound/lmms-0.4.0 [0.4.0_rc2] USE="alsa ogg -debug -fftw > -fluidsynth -jack -pulseaudio -sdl -stk (-vst) (-pch%) (-portaudio%)" 10,340 kB > > Wine is installed and I have set the "vst"-USE flag for lmms. > Alexis has p.use.masked vst support, because if libX11 is compiled with xcb support, and LIBXCB_ALLOW_SLOPPY_LOCK=1 is not set, it causes lmms to crash when opening the GUI of a VST plugin. Here it even locked up my X server completely. If you have libX11 with xcb on x86, could you please test if it also happens there? Just comment out/remove the line with "media-sound/lmms vst" from /usr/portage/profiles/base/package.use.mask Make sure LIBXCB_ALLOW_SLOPPY_LOCK is unset. Thanks!
