Summary: | New package: media-sound/sunvox-bin: A small, fast and powerful modular synthesizer/tracker | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Sophie Hamilton <gentoo-bugs> |
Component: | New packages | Assignee: | Default Assignee for New Packages <maintainer-wanted> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://www.warmplace.ru/soft/sunvox/ | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
sunvox-bin-1.9.4c.ebuild
License: SunVox sunvox-bin-1.9.4c.ebuild (with requested changes from comments #2 and #3) sunvox-bin-1.9.5.ebuild sunvox-bin-1.9.5d.ebuild sunvox-bin-1.9.6b.ebuild sunvox-bin-1.9.6b.ebuild sunvox-bin-2.0.ebuild sunvox-bin-2.0.ebuild sunvox-bin-2.0e.ebuild sunvox-bin-2.0e-r1.ebuild |
Description
Sophie Hamilton
2018-10-22 21:53:13 UTC
Created attachment 552450 [details]
License: SunVox
Comment on attachment 552448 [details] sunvox-bin-1.9.4c.ebuild >DESCRIPTION="A small, fast and powerful modular synthesizer/tracker." Please place no dot at the end of DESCRIPTION. It's not a sentence but more of a title. >DEPEND="" No need to set and empty DEPEND. >BDEPEND="" No need to set and empty BDEPEND. Comment on attachment 552450 [details]
License: SunVox
That looks pretty generic.
Created attachment 552686 [details] sunvox-bin-1.9.4c.ebuild (with requested changes from comments #2 and #3) New version of the ebuild with the corrections to DESCRIPTION, DEPEND, BDEPEND and LICENSE as requested. I've picked "freedist" as the generic license because that seems to be the closest one available, although I wasn't sure if the "There are no restrictions on the use of your own content created with this software." line in the original license was legally significant or not. BTW, is there a listing of generic licenses available? The closest thing I could find to any sort of metadata was /usr/portage/profiles/license_groups, which doesn't even have "freedist" listed. In the end I had to resort to using the command line to find the most-used licenses in the Portage tree, then finding one that looked relevant. Also, what's the BDEPEND variable used for? It's not documented at https://devmanual.gentoo.org/general-concepts/dependencies/index.html (or in the "Variables" section, either of the Dev Manual, either). Also, I meant to ask - is my usage of ABI_X86 to determine which version(s) to install correct? I know that ABI_X86 is normally used for libraries, but because it's important to install the correct binaries here, it seemed appropriate. I don't know if there's any better way of doing it except perhaps "if use amd64", and I don't know if that's an appropriate usage. Vote for this. So many good packages still doesn't icluded because of lack of maintainers. SunVox 1.9.5 has been released. The same ebuild can be used if it's version-bumped. Despite that, I'll upload a new one because I also noticed that I never actually put "New package" in the summary field, and also I never included a GCO sign-off on the old ebuild. My apologies. Created attachment 604038 [details] sunvox-bin-1.9.5.ebuild media-sound/sunvox-bin: new package Signed-off-by: Sophie Hamilton <gentoo-bugs@theblob.org> Created attachment 604040 [details] sunvox-bin-1.9.5d.ebuild I forgot to update the copyright on the ebuild, sorry! Signed-off-by: Sophie Hamilton <gentoo-bugs@theblob.org> Comment on attachment 604040 [details] sunvox-bin-1.9.5d.ebuild The existing ebuild can be used with SunVox 1.9.5d, so I'll just rename the attachment. Signed-off-by: Sophie Hamilton <gentoo-bugs@theblob.org> Created attachment 676336 [details]
sunvox-bin-1.9.6b.ebuild
SunVox 1.9.6b was released last week; here's an ebuild for it!
Changes to note in this ebuild:
* The new 'curves' directory from the archive is copied over if you have the 'examples' USE flag on.
* There is no longer a binary for CPUs that do not support SSSE3, so that USE flag has been removed.
* The binaries that are supplied are now pre-stripped. There's not much I'd be able to do about this other than set RESTRICT="strip" in the ebuild, but I'm not sure if this is what I'm supposed to do or not. There is a QA warning on install about this.
Created attachment 676339 [details] sunvox-bin-1.9.6b.ebuild I forgot to sign off my previous attachment, so I'll upload it again just in case it's necessary. See the previous comment for details; there are no differences. Signed-off-by: Sophie Hamilton <gentoo-bugs@theblob.org> Created attachment 763540 [details] sunvox-bin-2.0.ebuild Sunvox 2.0 was released yesterday! Changes in the ebuild: * Added the QA_PREBUILT variable to hint to Portage that we can't do anything with these binary files. * Cleaned up the dependency list to only include direct dependencies. * Added an "opengl" USE flag to allow installing of the new OpenGL binary for x86_64 systems. (There is no OpenGL binary for x86_32, so in these cases the regular SDL binary is installed.) This new ebuild *should* be compatible with EAPI 8 as far as I can tell, but I haven't yet updated to a compatible Portage so I cannot test that. Therefore, this ebuild only uses EAPI 7. Signed-off-by: Sophie Hamilton <gentoo-bugs@theblob.org> Created attachment 763542 [details] sunvox-bin-2.0.ebuild Oops, I forgot to change the copyright date in the header. Signed-off-by: Sophie Hamilton <gentoo-bugs@theblob.org> Created attachment 763543 [details] sunvox-bin-2.0e.ebuild ...pretend you didn't see that. *whistleS* Signed-off-by: Sophie Hamilton <gentoo-bugs@theblob.org> The same ebuild for 2.0 can be used for 2.0e, as well, which is why I haven't been updating it. I'll rename the attachment now, and I'll also remove the version number from the title of this bug. Signed-off-by: Sophie Hamilton <gentoo-bugs@theblob.org> Created attachment 844607 [details]
sunvox-bin-2.0e-r1.ebuild
Updating version dependency on libsdl2 to 2*
This should have been done back in August, but I didn't notice this until now. It appears that the ABI version remains at 2.0 so it doesn't seem to matter that we're using a newer version of libsdl2.
I've lightly tested the x86/x86_64 binaries that link to libsdl2 to make sure they still work with the newer libsdl2 versions and they seem to work, so I believe this should be good.
|