http://bugzilla.rpmfusion.org/show_bug.cgi?id=15
David Timms <[EMAIL PROTECTED]> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks|2 |3
--- Comment #45 from David Timms <[EMAIL PROTECTED]> 2008-12-02 13:34:52 ---
(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).
=====
(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.
--
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.
