spec hacks for vanilla and git-based kernel rpm builds

[Jarod Wilson]

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 at redhat.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-kernel-list/attachments/20070702/64614d40/attachment.sig>