[Bug 433738] Review Request: xf86-video-nouveau - X.org nouveau driver

bugzilla at redhat.com bugzilla at redhat.com
Fri Feb 22 23:51:03 UTC 2008


Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: xf86-video-nouveau - X.org nouveau driver


https://bugzilla.redhat.com/show_bug.cgi?id=433738





------- Additional Comments From tibbs at math.uh.edu  2008-02-22 18:51 EST -------
I have to admit that my git knowledge is a bit shallow, but I'm a bit confused
as to how you know what git revision to checkout to generate the tarball when
you don't have the tarball from which to extract the git revision.

Also, I don't think tare working quite properly; when the package is built,
you can't directly access %{tarfile} and even though it's a build dependency,
git-core isn't installed in the buildroot when the srpm is built.  So the end
the package gets a VR of just 0.0.10-0.20080221git.fc9 and you get this in the
build log:

sh: git-get-tar-commit-id: command not found
bzip2: Can't open input file xf86-video-nouveau-0.0.10-20080221.tar.bz2: No
  such file or directory.

For simplicity, I'd just suggest hardcoding the git_version, or even just
dropping it from the release (it's in no way mandatory) and just sticking it
in the instructional comments.

Once I extracted the commit-id from the tarball manually, I was able to follow
the comments in the spec to recreate the archive and verify that it matched,
although your instructions are missing a "cd xf86-video-nouveau".

Now, there are some new rpmlint complaints:

  xorg-x11-drv-nouveau.x86_64: W: incoherent-version-in-changelog 0.0.10-1 
   1:0.0.10-0.20080221git.fc9
See below; basically you want your changelog entry to match the actual EVR
you're using, although many folks skip the epoch.

  xorg-x11-drv-nouveau-debuginfo.x86_64: W: filename-too-long-for-joliet 
   xorg-x11-drv-nouveau-debuginfo-0.0.10-0.20080221git.fc9.x86_64.rpm
I guess this is unavoidable.

Other minor quibbles: Best to start your release at "1.whatever" instead of
"0.whatever" to distinguish it from the prerelease case.  (Prereleases count
up from 0.1, releases and post-release snapshots count up from 1.)

I don't quite understand the dependency on hwdata, since this package doesn't
install anything into /usr/share/hwdata.

Abbreviated checklist:
* source files match upstream (verified by manual untar/diff)
X doesn't quite meet the versioning guidelines (start post-release snapshots 
   from release 1.x, please)
* specfile is properly named and uses macros consistently.
X The git_version stuff seems somewhat convoluted and seems to not actually 
   work.
* summary is OK.
* description is OK.
* dist tag is present.
* build root is OK.
* license field matches the actual license.
* license is open source-compatible.
X license text not included in package.
* BuildRequires are proper.
* compiler flags are appropriate.
* %clean is present.
* package builds in mock (rawhide, x86_64).
* package installs properly
* debuginfo package looks complete.
X rpmlint has valid complaints.
? final provides and requires are sane:
   nouveau_drv.so()(64bit)
   xorg-x11-drv-nouveau = 1:0.0.10-0.20080221git.fc9
  =
?  hwdata
   kernel-drm-nouveau = 10
   xorg-x11-server-Xorg >= 1.3.0.0-6


-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.




More information about the Fedora-package-review mailing list