Spec URL: http://members.iinet.net.au/~timmsy/nes_ntsc/nes_ntsc.spec SRPM URL: http://members.iinet.net.au/~timmsy/nes_ntsc/nes_ntsc-0.2.2-1.fc9.src.rpm Description: NES NTSC video filter library. Pixel artifacts and color mixing play an important role in NES games console graphics. Accepts pixels in native 6-bit NES palette format, or a 9-bit format that includes the three color emphasis bits in PPU register $2001. Can also output an RGB palette for use in a regular blitter
Created attachment 313566 [details] diff between original dribble spec0.2.0 and this spec. I request some assistance regarding lib sonames. This library has previously been packaged and used by out of Fedora repo applications as libnes_ntsc.so.0.2.0 Have I gone about the soname change in an effective way ? Should I keep the original 0.2.0 soname instead ?
I plan on up/packaging upstreams other *_ntsc libs. The author mentions the latest release include a source cleanup and refactoring, so that some files are now identical between the 3x *_ntsc sources. Would it be acceptable/worth the effort to create a single libntsc package, that includes all three upstream source packages, with sub packages for -nes, -snes, -sms ?
(In reply to comment #2) > I plan on up/packaging upstreams other *_ntsc libs. The author mentions the > latest release include a source cleanup and refactoring, so that some files are > now identical between the 3x *_ntsc sources. Would it be acceptable/worth the > effort to create a single libntsc package, that includes all three upstream > source packages, with sub packages for -nes, -snes, -sms ? IMHO it is not worth the trouble and you could have a serious drawback. What if upstream update just -sms? You should make a new release for all three - and this is something unneeded by both end users (who would download a release for -nes and -snes for nothing) and for infrastructure (who would build a release for -nes and -snes for nothing). Separate packages is the way to go if upstream have separate independent sources.
(In reply to comment #3) ... > Separate packages is the way to go if upstream have separate independent > sources. Thanks, I thought that might be the case.
Full review done, no problems found: Approved!
Excellent, thanks Hans. New Package CVS Request ======================= Package Name: nes_ntsc Short Description: Provides a NES NTSC video filtering library Owners: dtimms.au Branches: F-8 F-9 InitialCC:
One further question: when a reference spec is used as the basis for a Fedora spec, is there a preference on keeping the original changelog entries ? I see value in acknowledging previous contributors and issues that occurred in getting the spec to it's pre-fedora state. On the other hand, is it allowed to include those old changelog entries ?
(In reply to comment #7) > One further question: when a reference spec is used as the basis for a Fedora > spec, is there a preference on keeping the original changelog entries ? > I see value in acknowledging previous contributors and issues that occurred in > getting the spec to it's pre-fedora state. On the other hand, is it allowed to > include those old changelog entries ? It is fine to keep the original entries. For example, I kept the old entries from hatari when I migrated it from Dribble to Fedora.
cvs done
nes_ntsc-0.2.2-1.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/nes_ntsc-0.2.2-1.fc9
nes_ntsc-0.2.2-1.fc8 has been submitted as an update for Fedora 8. http://admin.fedoraproject.org/updates/nes_ntsc-0.2.2-1.fc8
Correcting the status and assigning the request to j.w.r.degoede Thanks,
nes_ntsc-0.2.2-1.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
nes_ntsc-0.2.2-1.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.