This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 212513 - Review Request: sparse - source code semantec parser used by the Linux kernel
Review Request: sparse - source code semantec parser used by the Linux kernel
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Josh Boyer
Fedora Package Reviews List
:
: 185325 (view as bug list)
Depends On:
Blocks: FE-ACCEPT
  Show dependency treegraph
 
Reported: 2006-10-27 01:06 EDT by Matt Domsch
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version: 0-0.1.20061026git
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-06 08:08:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
kevin: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Matt Domsch 2006-10-27 01:06:48 EDT
Spec URL: http://domsch.com/linux/fedora/extras/sparse/sparse.spec
SRPM URL: http://domsch.com/linux/fedora/extras/sparse/sparse-0-0.1.20061026git.src.rpm
Description: 
Sparse is a semantic parser of source files: it's neither a compiler
(although it could be used as a front-end for one) nor is it a
preprocessor (although it contains as a part of it a preprocessing
phase).

It is meant to be a small - and simple - library.  Scanty and meager,
and partly because of that easy to use.  It has one mission in life:
create a semantic parse tree for some arbitrary user for further
analysis.  It's not a tokenizer, nor is it some generic context-free
parser.  In fact, context (semantics) is what it's all about - figuring
out not just what the grouping of tokens are, but what the _types_ are
that the grouping implies.

Sparse is primarily used in the development and debugging of the Linux kernel.
Comment 1 Jason Tibbitts 2006-10-27 01:09:34 EDT
*** Bug 185325 has been marked as a duplicate of this bug. ***
Comment 2 Matt Domsch 2006-10-27 08:44:54 EDT
bkyoung, I'm sorry I didn't see your review request when I went looking for
this.  I believe my spec is cleaner and per packaging guidelines, which should
accelerate the process.
Comment 3 Josh Boyer 2006-10-30 21:43:07 EST
Is there a reason not to use the snapshot tarballs that Dave Jones provides for
sparse at http://www.codemonkey.org.uk/projects/git-snapshots/sparse/ ?  Since
sparse really doesn't do releases, that is about as close as it comes.  Also,
does "git" really have to be in the alphatag?

Other than that, the package looks fairly clean.  rpmlint doesn't complain about
anything, license is fine, and the package builds on i386 just fine.  I'll test
ppc later.
Comment 4 Matt Domsch 2006-10-30 23:44:59 EST
re: tarballs - doesn't honestly matter to me if the package has a daily snapshot
tarball or a git clone'd tarball from a given day.  I can put a comment in that
snapshot tarballs are also available at DaveJ's site, or can use his tarballs
directly, either way.

re: git in the alphatag, that's a figment of git clone method above and
Packaging/NamingGuidelines says to use it.  I suppose if I used one of the
snapshot tarballs, that could be dropped, though NamingGuidelines doesn't really
cover this scenario exactly (a non-project-released snapshot tarball).  Spot?

Thanks for the additional review and comments.  Package builds and works on
x86_64 for me too btw; I haven't tried ppc.
Comment 5 Tom "spot" Callaway 2006-10-31 09:56:42 EST
If you're using a manually created git clone, then yeah, the git in the alphatag
should be there. If you use one of the snapshots from upstream, then you don't
have to.
Comment 6 Josh Boyer 2006-10-31 10:00:45 EST
(In reply to comment #4)
> re: tarballs - doesn't honestly matter to me if the package has a daily snapshot
> tarball or a git clone'd tarball from a given day.  I can put a comment in that
> snapshot tarballs are also available at DaveJ's site, or can use his tarballs
> directly, either way.
> 
> re: git in the alphatag, that's a figment of git clone method above and
> Packaging/NamingGuidelines says to use it.  I suppose if I used one of the
> snapshot tarballs, that could be dropped, though NamingGuidelines doesn't really
> cover this scenario exactly (a non-project-released snapshot tarball).  Spot?

Well, the only reason I suggested the DaveJ snapshots was to basically avoid the
git in the alphatag.  It's not really a big deal to me.

> Thanks for the additional review and comments.  Package builds and works on
> x86_64 for me too btw; I haven't tried ppc.

I don't expect problems on ppc.  It should just work.
Comment 7 Josh Boyer 2006-11-03 22:18:07 EST
GOOD
====
* Package and spec named appropriately: See note below
* Spec file is legible and in Am. English
* Source matches upstream: See note below
* No unnecessary BuildRequires
* No locales
* No shared libraries in the default linker path
* RPM_BUILD_ROOT cleaned where appropriate
* Not relocatable
* No duplicate %files
* File permissions look ok
* No need for a -devel subpackage
* Not a gui program; no need for a .desktop file
* Consistent use of macros
* Does not own any directories that it should not own.

Note: I've sent an email to the upstream developers discussing a possible
official release.  If that comes to pass, we can use those for this package. 
Until then, git or tarball snapshots will work just fine.

This package builds fine on ppc.  This passes review.
Comment 8 Matt Domsch 2006-11-06 08:08:28 EST
packages built and released, closing.
Comment 9 Matt Domsch 2007-07-11 17:42:17 EDT
Please transfer ownership of sparse on all branches to Roland McGrath.
Comment 10 Kevin Fenzi 2007-07-11 21:58:29 EDT
cvs done. 

Note You need to log in before you can comment on or make changes to this bug.