Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 212513 - Review Request: sparse - source code semantec parser used by the Linux kernel
Summary: Review Request: sparse - source code semantec parser used by the Linux kernel
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Josh Boyer
QA Contact: Fedora Package Reviews List
URL:
Whiteboard:
: 185325 (view as bug list)
Depends On:
Blocks: FE-ACCEPT
TreeView+ depends on / blocked
 
Reported: 2006-10-27 05:06 UTC by Matt Domsch
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version: 0-0.1.20061026git
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-11-06 13:08:28 UTC
Type: ---
Embargoed:
kevin: fedora-cvs+

Attachments (Terms of Use)

Description Matt Domsch 2006-10-27 05:06:48 UTC 
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 05:09:34 UTC 
*** Bug 185325 has been marked as a duplicate of this bug. ***
Comment 2 Matt Domsch 2006-10-27 12:44:54 UTC 
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-31 02:43:07 UTC 
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-31 04:44:59 UTC 
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 14:56:42 UTC 
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 15:00:45 UTC 
(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-04 03:18:07 UTC 
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 13:08:28 UTC 
packages built and released, closing.
Comment 9 Matt Domsch 2007-07-11 21:42:17 UTC 
Please transfer ownership of sparse on all branches to Roland McGrath.
Comment 10 Kevin Fenzi 2007-07-12 01:58:29 UTC 
cvs done.
Note You need to log in before you can comment on or make changes to this bug.