[Bug 15] Review Request: bsnes - SNES emulator focused on accuracy

[RPM Fusion Bugzilla]

http://bugzilla.rpmfusion.org/show_bug.cgi?id=15





--- Comment #46 from Julian Sikorski <belegdol at gmail.com>  2008-12-02 14:59:12 ---
Thank you for your approval!

(In reply to comment #45)
> (In reply to comment #44)
> > > > [ x ] source URL is incorrect:
> > > >   think it should be: ...%{name}_v0.%{vernumber}...
> > > >   upstream calls it 037a but compresses source to v0.037a
> > > 
> > > I'm not sure what you mean here, that's how the upstream tarball is called
> Oops, I pasted the source url into web browser, then subsituted name and
> version (instead of vernumber), and hence thought the source0 URL was incorrect
> because I received a 404.
> 
> In fact that SourceURL is correct, as you noted. Ignore that ;)
> 
> > > (I'm aware it uncompresses to a folder of slightly different name. Besides,
> > > if the Source0 URL would be incorrect, the package won't build, would it? 
> > 
> > What an awful grammar. Should be: “Besides, if the Source0 URL were
> > incorrect, the package wouldn't build, would it?”
> Yes, the package will still build.
> 
> Unless I'm mistaken, the process when we are constructing SRPMs is to manually
> download the mentioned source0 into our ~/rpmbuild/SOURCES folder. Then we run
> rpmbuild which reads the .spec and archives that ~/rpmbuild/SOURCES/source0
> file into a .src.rpm. Neither rpmbuild -bs or -ba actually retrieve the
> mentioned sources direct from the internet.
> 
> That is why we get reviewers to compare md5sums between upstream download URLs,
> and the source included in the .src.rpm to check the source is clean. When the
> package is imported into cvs, the packager imports the approved .src.rpm. This
> extracts the main source, and uploads it to the cvs-lookaside cache. The build
> system uses this source straight out of the .src.rpm the packager created (so
> we best be sure the source is not tainted).

Yes, the actual URL does not matter, only the filename at the end of it does.
But the filename is what you were suggesting was incorrect.
%{name}_v0.%{vernumber} would translate to bsnes_v0.037a.zip, which is not how
the file is called.

> =====
> (In reply to comment #42)
> > (In reply to comment #41)
> > > Spec URL: http://belegdol.republika.pl/rpmstuff/bsnes.spec
> > > SRPM URL: http://belegdol.republika.pl/rpmstuff/bsnes-0.037a-4.fc10.src.rpm
> ...
> > Julian: I think we are really close here, just a few items above {x and ?} to
> > either fix or provide reasoning for. Reading back over the review, it seems
> > you have completed pretty well all requests reviewers have made, beside the
> > "make it use all system libaries". If there are other reviewers who believe
> > further work should be done on the "use system libraries" item, can you
> > please speak up now ?
> Noting replies on rpmfusion-devel:
> - "packager should at least trace (e.g. in comments) which
> system libraries are not used and why."
> - "If there are strong reasons not to this should be documented case by case
> with comments in the spec file"
> - "enough of a diversion from the standard snes_ntsc library to warrant an
> exception"
> - my own reading of the code "the modified video processing filter algorithm
> calls back into bsnes specific c++ colortable code, that isn't available when
> the library is built stand alone"
> 
> With some small notes included in the spec to the fact
> - the application is built with modified private copy of the snes_ntsc filter,
> - Exclusive arch reason being that libco is only available on these platforms,
> 
> I (David Timms) approve this package bsnes.
> 
OK, I will add these comments upon import.


-- 
Configure bugmail: http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.