> 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}.
> 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.
_______________________________________________
Fedora-kernel-list mailing list
Fedora-kernel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
