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@xxxxxxxxxx
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Fedora-kernel-list mailing list Fedora-kernel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-kernel-list
