Roland McGrath wrote:
> So I finally got around to poking at these bits again myself (in
> relation to bug 240878), but ran into an issue with a vanilla/nopatches
> build:
>
> $ rpmbuild -bb --with baseonly --define 'nopatches 1' kernel-2.6.spec
> RPM build errors:
> File not found:
>
/data/buildroot/tmp/kernel-2.6.21-1.3243.fc8-root-x86_64/usr/src/debug/kernel-vanilla-2.6.21/linux-2.6.21.x86_64
>
> There exists a .../debug/kernel-2.6.21/linux-2.6.21.x86_64 though.
> (Looking into it more now, but figured I'd throw it out there, in case
> someone already knows what's up).
Hmm. There are various magic things that use %{name} and others that use
"kernel" explicitly. I'm sure this worked when I checked the stuff in.
So
something must have changed. I had to tweak something or other because of
this issue, probably the %setup -n arg, but I don't quite recall. I made
it use plain kernel-%{version} for the source dir name mostly so that an
rpmbuild in your working dir reuses the kernel-V/vanilla dir and links.
For having both installed in debuginfo rpms, it might make more sense to
let it all use %{name}.
It looks like all the debug stuff is in a directory structure that
matches whatever resulted from %setup, and the %files section references
them using %{name}, but needs to use "kernel" instead of %{name}.
> Also, anyone have thoughts on re-versioning, at least in the
vanilla
> case, so as to more accurately describe what's being built? For example,
> the above is 2.6.22-rc4-git6, so I'm a fan of the package that gets
> churned out being kernel-vanilla-2.6.22-0.1.rc4.git6.fc8 or some such
> thing, instead of kernel-vanilla-2.6.21-1.3243.fc8.
My gen-patches script used for the git-based rpms does something vaguely
like this based on: git describe | sed 's/-g[0-9a-f]*$//;s/-/./g;s/^v//'.
The -gitN names are not actual tags so git tools don't tell you about them,
but the newfangled git-describe "number of commits since" version number
makes for something that increases and can be resolved into an upstream rev.
I just sent off a spec diff a few minutes ago that basically implements
what I was thinking of (and now I see you've already commented on...).
The main rc and git numbers I was interested in are those from the
upstream Linus tree snapshots, which usually end up getting manually
entered in the form of the patches added to the build, so I figured no
magic necessary. The new stuff should interoperate with your bits as
well for other-tree-git-based rpms too though.
--
Jarod Wilson
jwilson(a)redhat.com