Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=510668 --- Comment #17 from Orcan 'oget' Ogetbil <oget.fedora@xxxxxxxxx> 2009-08-22 02:46:08 EDT --- Yay! Finally! I'm very sorry for the delay (In reply to comment #13) > > * naming: TODO > - name matches upstream > - spec file name matches package name > - snapshot release tag (assuming it is a post-release snapshot) should contain > the date (the svnrev can be appended, but the date is required) > ( according to > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Snapshot_packages ) > Added > > * License: TODO > - the package contains sources under the GPLv2, too: > src/import/pmidi/except.c (GPLv2 as published), most likely this means > that the complete package must be released as GPLv2 > - the source package (and the built binary package) contain lots of examples > and so it is necessary to check their legal status - in the worst case they > must not only be stripped out from the binary but also from the sources - do > you have any information whether they are distributable? > - license file packaged: if the final package would be GPLv2, then we should > not package GPLv1 > I removed the midi and the xml files which have unclear licenses. Also removed a can file with bad license. I created a new tarball and gave the instructions. Upstream told me the program itself is GPLv2. > * Sources: OK > - Source0 URL ok > - spectool -g canorus.spec works > - sources matches upstream - md5sum: > 2dc201fec21d781d0add487c5a9ed35b canorus_0.7svn.R1163_source.tar.bz2 > - even if the URL for the nightly builds is linked directly from canorus' > homepage it is a little bit strange to use plain IP addresses here - let's hope > that upstream does an official release soon and the URL can be changed again to > something like this: > http://prdownload.berlios.de/canorus/canorus_0.7.R1002_source.tar.bz2 > Yes, I will turn to regular release tarballs when the software turns more stable. > > * Locales handling: TODO > The package contains language files in a non-gettext format (*.qm files). > Is it necessary to add them also via the %lang(xx) tag? > Yes, we do this with qt applications. For instance, I was asked in the past explicitly to mark the .qm files as %lang(xx) for qjackctl and qsynth > > * code vs. content: TODO > - see above (license issues) > - package contains example midi files, sheets of music, etc. (3.5 MB) > - according to the guidelines examples in general are not considered as > content, but if they e.g. contain notes from music which is still under > copyright I assume it would not be permissable... > See above > > * functional test: TODO > - program segfaults when it is closed > - program segfaults when opening any of the musicxml examples > Yes, the last time I talked to them on IRC upstream knew about the issue. But I didn't contact them in the past 3-4 weeks (I was too busy) so I don't know what is the current situation. Upstream had told me before that canorus is still alpha quality, for the time being. But they did a good job for a start and I see it worth packaging. Spec URL: http://oget.fedorapeople.org/review/canorus.spec SRPM URL: http://oget.fedorapeople.org/review/canorus-0.7-3.R1177.20090804svn.fc11.src.rpm koji rawhide build: http://koji.fedoraproject.org/koji/taskinfo?taskID=1624776 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review