2015-06-30 11:48:15

by Espen Carlsen

[permalink] [raw]
Subject: [PATCH, resend] build: fix broken kernel RPM source symlink

Fix the 'rpm-pkg' makefile target to always generate the correct
/usr/src/kernel/<ver> symlink; this fails on non-RPM-native systems
eg Ubuntu.

On a non-RPM-native system, the symlink created by rpmbuild points to
the source tree, so the ln -sf commands to overwrite build and source will
create a new link inside the directory pointed to by the build and source
symlinks. This will break the -devel.rpm, as the build and source symlinks
will point to non existing directories after installing them.

Candidate for stable.

Signed-off-by: Espen Carlsen <[email protected]>
---
scripts/package/mkspec | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/package/mkspec b/scripts/package/mkspec
index d9ab94b..2d28d48 100755
--- a/scripts/package/mkspec
+++ b/scripts/package/mkspec
@@ -123,8 +123,8 @@ echo "mkdir -p "'$RPM_BUILD_ROOT'"/usr/src/kernels/$KERNELRELEASE"
echo "EXCLUDES=\"$RCS_TAR_IGNORE --exclude .tmp_versions --exclude=*vmlinux* --exclude=*.o --exclude=*.ko --exclude=*.cmd --exclude=Documentation --exclude=firmware --exclude .config.old --exclude .missing-syscalls.d\""
echo "tar "'$EXCLUDES'" -cf- . | (cd "'$RPM_BUILD_ROOT'"/usr/src/kernels/$KERNELRELEASE;tar xvf -)"
echo 'cd $RPM_BUILD_ROOT'"/lib/modules/$KERNELRELEASE"
-echo "ln -sf /usr/src/kernels/$KERNELRELEASE build"
-echo "ln -sf /usr/src/kernels/$KERNELRELEASE source"
+echo "ln -sfT /usr/src/kernels/$KERNELRELEASE build"
+echo "ln -sfT /usr/src/kernels/$KERNELRELEASE source"
fi

echo ""
--
1.9.1


2015-07-05 08:46:58

by Paul Bolle

[permalink] [raw]
Subject: Re: [PATCH, resend] build: fix broken kernel RPM source symlink

On di, 2015-06-30 at 13:47 +0200, Espen Carlsen wrote:
> Fix the 'rpm-pkg' makefile target to always generate the correct
> /usr/src/kernel/<ver> symlink; this fails on non-RPM-native systems

/kernels/

> eg Ubuntu.
>
> On a non-RPM-native system, the symlink created by rpmbuild points to
> the source tree, so the ln -sf commands to overwrite build and source
> will
> create a new link inside the directory pointed to by the build and
> source
> symlinks. This will break the -devel.rpm, as the build and source
> symlinks
> will point to non existing directories after installing them.

Perhaps this is all obvious but what exactly happens currently and what
happens after this change? (An example might help readers that are just
as easily confused as I am. Perhaps that might also explain why this is
only an issue on non-RPM-native systems.)

It doesn't help that the description of -T in "man ln" is rather
unhelpful. "info ln" was better, after following some references, but
I'm still not sure what it buys you for this issue.

> --- a/scripts/package/mkspec
> +++ b/scripts/package/mkspec

> -echo "ln -sf /usr/src/kernels/$KERNELRELEASE build"
> -echo "ln -sf /usr/src/kernels/$KERNELRELEASE source"
> +echo "ln -sfT /usr/src/kernels/$KERNELRELEASE build"
> +echo "ln -sfT /usr/src/kernels/$KERNELRELEASE source"

Thanks,


Paul Bolle

2015-07-06 19:37:25

by Espen Carlsen

[permalink] [raw]
Subject: RE: [PATCH, resend] build: fix broken kernel RPM source symlink

> From: Paul Bolle [mailto:[email protected]] On di, 2015-06-30 at
> 13:47 +0200, Espen Carlsen wrote:
> > Fix the 'rpm-pkg' makefile target to always generate the correct
> > /usr/src/kernel/<ver> symlink; this fails on non-RPM-native systems
> /kernels/
> > eg Ubuntu.
> > On a non-RPM-native system, the symlink created by rpmbuild points
> > to the source tree, so the ln -sf commands to overwrite build and
> > source will create a new link inside the directory pointed to by the
> > build and source symlinks. This will break the -devel.rpm, as the
> > build and source symlinks will point to non-existing directories
> > after installing them.
> Perhaps this is all obvious but what exactly happens currently and
> what happens after this change? (An example might help readers that
> are just as easily confused as I am. Perhaps that might also explain
> why this is only an issue on non-RPM-native systems.)

In my examples, kernel-4.1.0.spec is the kernel.spec file generated from mkspec with the two ln -sf lines commented out to show how it works.
This is the how BUILDROOT looks after rpmbuild -bi kernel-4.1.0.spec on an Ubuntu system, notice that on Ubuntu, there are already a 'build' and 'source' symlink before the ln -sf commands are issued, CentOS however doesn't have those links on the same step.
user@build-ubuntu:/srv/user/rpmbuild$ rpmbuild -bi SPECS/kernel-4.1.0.spec
user@build-ubuntu:/srv/user/rpmbuild$ cd BUILDROOT/kernel-4.1.0-1.x86_64/lib/modules/4.1.0/
user@build-ubuntu:/srv/user/rpmbuild/BUILDROOT/kernel-4.1.0-1.x86_64/lib/modules/4.1.0$ ls -gG
total 64
lrwxrwxrwx 1 35 Jul 6 18:56 build -> /srv/user/rpmbuild/BUILD/kernel-4.1.0
drwxr-xr-x 5 4096 Jul 6 19:00 kernel
-rw-r--r-- 1 640 Jul 6 19:00 modules.alias
-rw-r--r-- 1 1272 Jul 6 19:00 modules.alias.bin
-rw-r--r-- 1 8897 Jul 6 19:00 modules.builtin
-rw-r--r-- 1 11866 Jul 6 19:00 modules.builtin.bin
-rw-r--r-- 1 1155 Jul 6 19:00 modules.dep
-rw-r--r-- 1 2056 Jul 6 19:00 modules.dep.bin
-rw-r--r-- 1 52 Jul 6 19:00 modules.devname
-rw-r--r-- 1 682 Jul 6 19:00 modules.order
-rw-r--r-- 1 131 Jul 6 19:00 modules.softdep
-rw-r--r-- 1 1419 Jul 6 19:00 modules.symbols
-rw-r--r-- 1 1484 Jul 6 19:00 modules.symbols.bin
lrwxrwxrwx 1 35 Jul 6 19:00 source -> /srv/user/rpmbuild/BUILD/kernel-4.1.0
user@build-ubuntu:/srv/user/rpmbuild/BUILDROOT/kernel-4.1.0-1.x86_64/lib/modules/4.1.0$

Now when you manually do the ln -sf ln -sf /usr/src/kernels/4.1.0,
user@build-ubuntu:/srv/user/rpmbuild/BUILDROOT/kernel-4.1.0-1.x86_64/lib/modules/4.1.0$ ln -sf /usr/src/kernels/4.1.0 build
user@build-ubuntu:/srv/user/rpmbuild/BUILDROOT/kernel-4.1.0-1.x86_64/lib/modules/4.1.0$ ln -sf /usr/src/kernels/4.1.0 source
user@build-ubuntu:/srv/user/rpmbuild/BUILDROOT/kernel-4.1.0-1.x86_64/lib/modules/4.1.0$ ls -gG
total 64
lrwxrwxrwx 1 35 Jul 6 18:56 build -> /srv/user/rpmbuild/BUILD/kernel-4.1.0
drwxr-xr-x 5 4096 Jul 6 19:00 kernel
-rw-r--r-- 1 640 Jul 6 19:00 modules.alias
-rw-r--r-- 1 1272 Jul 6 19:00 modules.alias.bin
-rw-r--r-- 1 8897 Jul 6 19:00 modules.builtin
-rw-r--r-- 1 11866 Jul 6 19:00 modules.builtin.bin
-rw-r--r-- 1 1155 Jul 6 19:00 modules.dep
-rw-r--r-- 1 2056 Jul 6 19:00 modules.dep.bin
-rw-r--r-- 1 52 Jul 6 19:00 modules.devname
-rw-r--r-- 1 682 Jul 6 19:00 modules.order
-rw-r--r-- 1 131 Jul 6 19:00 modules.softdep
-rw-r--r-- 1 1419 Jul 6 19:00 modules.symbols
-rw-r--r-- 1 1484 Jul 6 19:00 modules.symbols.bin
lrwxrwxrwx 1 35 Jul 6 19:00 source -> /srv/user/rpmbuild/BUILD/kernel-4.1.0
user@build-ubuntu:/srv/user/rpmbuild/BUILDROOT/kernel-4.1.0-1.x86_64/lib/modules/4.1.0$

As you can see, the 'build' and 'source' symlink still points to the same directory as it did before the ln command was issued.
Also you can see in the directory pointed to by the 'build' symlink, that a link to the /usr/src/kernels/4.1.0 was created as '4.1.0':
user@build-ubuntu:/srv/user/rpmbuild/BUILDROOT/kernel-4.1.0-1.x86_64/lib/modules/4.1.0$ ls -gG build/
total 47084
lrwxrwxrwx 1 22 Jul 6 19:03 4.1.0 -> /usr/src/kernels/4.1.0
-rw-r--r-- 1 18693 Jun 30 12:30 COPYING
drwxr-xr-x 108 12288 Jun 30 12:30 Documentation
-rw-r--r-- 1 2163 Jun 30 12:30 Kbuild
-rw-r--r-- 1 252 Jun 30 12:30 Kconfig
-rw-r--r-- 1 54359 Jun 30 12:30 Makefile
-rw-r--r-- 1 455465 Jul 6 19:00 Module.symvers
-rw-r--r-- 1 3268556 Jul 6 19:00 System.map
drwxr-xr-x 33 4096 Jul 6 19:00 arch
drwxr-xr-x 3 4096 Jul 6 18:58 block
drwxr-xr-x 4 4096 Jul 6 18:58 crypto
drwxr-xr-x 122 4096 Jul 6 19:00 drivers
drwxr-xr-x 36 4096 Jul 6 19:00 firmware
drwxr-xr-x 76 12288 Jul 6 18:59 fs
drwxr-xr-x 30 4096 Jul 4 18:15 include
drwxr-xr-x 2 4096 Jul 6 19:00 init
drwxr-xr-x 2 4096 Jul 6 18:58 ipc
drwxr-xr-x 16 12288 Jul 6 18:59 kernel
-rw-r--r-- 1 3662 Jul 4 18:20 kernel.spec
drwxr-xr-x 11 20480 Jul 6 18:59 lib
drwxr-xr-x 3 12288 Jul 6 18:58 mm
-rw-r--r-- 1 8897 Jul 6 18:58 modules.builtin
-rw-r--r-- 1 682 Jul 6 19:00 modules.order
drwxr-xr-x 59 4096 Jul 6 19:00 net
drwxr-xr-x 15 4096 Jun 30 12:30 samples
drwxr-xr-x 14 4096 Jul 6 19:00 scripts
drwxr-xr-x 9 4096 Jul 6 18:58 security
drwxr-xr-x 23 4096 Jul 6 18:59 sound
drwxr-xr-x 21 4096 Jun 30 12:30 tools
drwxr-xr-x 2 4096 Jul 6 18:58 usr
drwxr-xr-x 3 4096 Jun 30 12:30 virt
-rwxr-xr-x 1 24870599 Jul 6 19:00 vmlinux
-rw-r--r-- 1 26536701 Jul 6 19:00 vmlinux.o
user@build-ubuntu:/srv/user/rpmbuild/BUILDROOT/kernel-4.1.0-1.x86_64/lib/modules/4.1.0$

Now, if I instead add -T to the ln command, like this:
user@build-ubuntu:/srv/user/rpmbuild/BUILDROOT/kernel-4.1.0-1.x86_64/lib/modules/4.1.0$ ln -sfT /usr/src/kernels/4.1.0 build
user@build-ubuntu:/srv/user/rpmbuild/BUILDROOT/kernel-4.1.0-1.x86_64/lib/modules/4.1.0$ ln -sfT /usr/src/kernels/4.1.0 source
user@build-ubuntu:/srv/user/rpmbuild/BUILDROOT/kernel-4.1.0-1.x86_64/lib/modules/4.1.0$ ls -gG
total 64
lrwxrwxrwx 1 22 Jul 6 19:06 build -> /usr/src/kernels/4.1.0
drwxr-xr-x 5 4096 Jul 6 19:00 kernel
-rw-r--r-- 1 640 Jul 6 19:00 modules.alias
-rw-r--r-- 1 1272 Jul 6 19:00 modules.alias.bin
-rw-r--r-- 1 8897 Jul 6 19:00 modules.builtin
-rw-r--r-- 1 11866 Jul 6 19:00 modules.builtin.bin
-rw-r--r-- 1 1155 Jul 6 19:00 modules.dep
-rw-r--r-- 1 2056 Jul 6 19:00 modules.dep.bin
-rw-r--r-- 1 52 Jul 6 19:00 modules.devname
-rw-r--r-- 1 682 Jul 6 19:00 modules.order
-rw-r--r-- 1 131 Jul 6 19:00 modules.softdep
-rw-r--r-- 1 1419 Jul 6 19:00 modules.symbols
-rw-r--r-- 1 1484 Jul 6 19:00 modules.symbols.bin
lrwxrwxrwx 1 22 Jul 6 19:06 source -> /usr/src/kernels/4.1.0
user@build-ubuntu:/srv/user/rpmbuild/BUILDROOT/kernel-4.1.0-1.x86_64/lib/modules/4.1.0$

You can see that it overwrites the existing symlink with the correct one instead of creating a new link inside the directory pointed to by the old symlink.

To sum it all up, without the change to mkspec, the package 'kernel-devel' package generated on an Ubuntu system is broken, as '/lib/modules/4.1.0/build' points to a directory that will not be on the server where the package is installed on:
user@build-ubuntu:/srv/user/rpmbuild/RPMS/x86_64$ rpm -qplv kernel-devel-4.1.0-1.x86_64.rpm
lrwxrwxrwx 1 root root 35 Jul 4 18:31 /lib/modules/4.1.0/build -> /srv/user/rpmbuild/BUILD/kernel-4.1.0
lrwxrwxrwx 1 root root 35 Jul 6 12:15 /lib/modules/4.1.0/source -> /srv/user/rpmbuild/BUILD/kernel-4.1.0
drwxr-xr-x 2 root root 0 Jul 6 12:15 /usr/src/kernels/4.1.0

> It doesn't help that the description of -T in "man ln" is rather
> unhelpful. "info ln" was better, after following some references, but
> I'm still not sure what it buys you for this issue.

> > --- a/scripts/package/mkspec
> > +++ b/scripts/package/mkspec
>
> > -echo "ln -sf /usr/src/kernels/$KERNELRELEASE build"
> > -echo "ln -sf /usr/src/kernels/$KERNELRELEASE source"
> > +echo "ln -sfT /usr/src/kernels/$KERNELRELEASE build"
> > +echo "ln -sfT /usr/src/kernels/$KERNELRELEASE source"

Espen Carlsen

2015-07-08 14:26:35

by Paul Bolle

[permalink] [raw]
Subject: Re: [PATCH, resend] build: fix broken kernel RPM source symlink

On ma, 2015-07-06 at 21:37 +0200, Espen Carlsen wrote:
> To sum it all up, without the change to mkspec, the package 'kernel
> -devel' package generated on an Ubuntu system is broken, as
> '/lib/modules/4.1.0/build' points to a directory that will not be on
> the server where the package is installed on:
> user@build-ubuntu:/srv/user/rpmbuild/RPMS/x86_64$ rpm -qplv kernel-devel-4.1.0-1.x86_64.rpm
> lrwxrwxrwx 1 root root 35 Jul 4 18:31 /lib/modules/4.1.0/build -> /srv/user/rpmbuild/BUILD/kernel-4.1.0
> lrwxrwxrwx 1 root root 35 Jul 6 12:15 /lib/modules/4.1.0/source -> /srv/user/rpmbuild/BUILD/kernel-4.1.0
> drwxr-xr-x 2 root root 0 Jul 6 12:15 /usr/src/kernels/4.1.0

And you want this to read
lrwxrwxrwx 1 root root 35 Jul 4 18:31 /lib/modules/4.1.0/build -> /usr/src/kernels/4.1.0
lrwxrwxrwx 1 root root 35 Jul 6 12:15 /lib/modules/4.1.0/source -> /usr/src/kernels/4.1.0
drwxr-xr-x 2 root root 0 Jul 6 12:15 /usr/src/kernels/4.1.0

or something equivalent, right?


Paul Bolle

2015-07-08 15:42:34

by Espen Carlsen

[permalink] [raw]
Subject: RE: [PATCH, resend] build: fix broken kernel RPM source symlink

From: Paul Bolle [mailto:[email protected]]
> On ma, 2015-07-06 at 21:37 +0200, Espen Carlsen wrote:
> And you want this to read
> lrwxrwxrwx 1 root root 35 Jul 4 18:31 /lib/modules/4.1.0/build -> /usr/src/kernels/4.1.0
> lrwxrwxrwx 1 root root 35 Jul 6 12:15
> /lib/modules/4.1.0/source -> /usr/src/kernels/4.1.0
> drwxr-xr-x 2 root root 0 Jul 6 12:15 /usr/src/kernels/4.1.0
> or something equivalent, right?

Correct. And modifying the two ln -sf commands in mkspec makes that happen on a Ubuntu system.
I have tested my suggested changes on:
CentOS 6.5, 7.0, Ubuntu 14.04 and 12.04. After the patch the kernel-devel package will be correct on all systems.
Without the patch, only CentOS generates correct packages.

Espen

2015-07-08 16:18:09

by Paul Bolle

[permalink] [raw]
Subject: Re: [PATCH, resend] build: fix broken kernel RPM source symlink

On wo, 2015-07-08 at 17:42 +0200, Espen Carlsen wrote:
> I have tested my suggested changes on:
> CentOS 6.5, 7.0, Ubuntu 14.04 and 12.04. After the patch the kernel
> -devel package will be correct on all systems.
> Without the patch, only CentOS generates correct packages.

Wild guess: do the Ubuntu systems already have
/lib/modules/4.1.0/build
/lib/modules/4.1.0/source

as symlinks to /usr/src/kernels/4.1.0 when you're building the rpms?
(That is, not in rpm's buildroot, but in the actual filesystem.)


Paul Bolle

2015-07-08 16:56:29

by Paul Bolle

[permalink] [raw]
Subject: Re: [PATCH, resend] build: fix broken kernel RPM source symlink

[I resisted looking into the flood of info you included in this message.
But this part could turn out to be interesting.]

On ma, 2015-07-06 at 21:37 +0200, Espen Carlsen wrote:
> This is the how BUILDROOT looks after rpmbuild -bi kernel-4.1.0.spec
> on an Ubuntu system, notice that on Ubuntu, there are already a
> 'build' and 'source' symlink before the ln -sf commands are issued,
> CentOS however doesn't have those links on the same step.
> user@build-ubuntu:/srv/user/rpmbuild$ rpmbuild -bi SPECS/kernel-4.1.0.spec

That is outside the realm of "make rpm".

I assume kernel-4.1.0.spec was a copy, somehow made, of kernel.spec as
was created by "make rpm". Does it matter, for the issue you ran into,
whether "make rpm" or "rpmbuild -bb SPECS/kernel.spec" is involved?

> user@build-ubuntu:/srv/user/rpmbuild/BUILDROOT/kernel-4.1.0-1.x86_64/lib/modules/4.1.0$ ls -gG
> total 64
> lrwxrwxrwx 1 35 Jul 6 18:56 build -> /srv/user/rpmbuild/BUILD/kernel-4.1.0
> [...]
> lrwxrwxrwx 1 35 Jul 6 19:00 source -> /srv/user/rpmbuild/BUILD/kernel-4.1.0

These two links are, I think, generated in this snippet from the main
Makefile:
_modinst_:
@rm -rf $(MODLIB)/kernel
@rm -f $(MODLIB)/source
@mkdir -p $(MODLIB)/kernel
@ln -s `cd $(srctree) && /bin/pwd` $(MODLIB)/source
@if [ ! $(objtree) -ef $(MODLIB)/build ]; then \
rm -f $(MODLIB)/build ; \
ln -s $(CURDIR) $(MODLIB)/build ; \
fi
@cp -f $(objtree)/modules.order $(MODLIB)/
@cp -f $(objtree)/modules.builtin $(MODLIB)/
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modinst

I wonder why you don't see similar links when building on CentOS. I saw
similar links in rpm's BUILDROOT when building on Fedora 22.

Thanks,


Paul Bolle

2015-07-08 18:47:25

by Espen Carlsen

[permalink] [raw]
Subject: RE: [PATCH, resend] build: fix broken kernel RPM source symlink

> From: Paul Bolle [mailto:[email protected]]
> On wo, 2015-07-08 at 17:42 +0200, Espen Carlsen wrote:
> Wild guess: do the Ubuntu systems already have
> /lib/modules/4.1.0/build
> /lib/modules/4.1.0/source
> as symlinks to /usr/src/kernels/4.1.0 when you're building the rpms?
> (That is, not in rpm's buildroot, but in the actual filesystem.)

No, I don't have any 4.x kernels installed on that system, just 3.16 Ubuntu kernel.
I assume your wild guess was that if I had /lib/modules/4.1.0/build & source as that was the kernel I was building?

Also, so you know, the issue isn't related to the 4.1.0 kernel, I can reproduce this on 4.0.x, 3.19.x and 3.18.x.
Probably others also, but those are the ones I've tried.
On all of them when I compile on Ubuntu, there will be a build and source softlink in the lib/modules/version/ directory
of BUILDROOT.

Espen

2015-07-08 18:52:43

by Paul Bolle

[permalink] [raw]
Subject: Re: [PATCH, resend] build: fix broken kernel RPM source symlink

On wo, 2015-07-08 at 20:47 +0200, Espen Carlsen wrote:
> I assume your wild guess was that if I had /lib/modules/4.1.0/build &
> source as that was the kernel I was building?

Yes.


Paul Bolle

2015-07-09 09:30:14

by Espen Carlsen

[permalink] [raw]
Subject: RE: [PATCH, resend] build: fix broken kernel RPM source symlink

> From: Paul Bolle [mailto:[email protected]]
> [I resisted looking into the flood of info you included in this message.
> But this part could turn out to be interesting.]
> On ma, 2015-07-06 at 21:37 +0200, Espen Carlsen wrote:
> > This is the how BUILDROOT looks after rpmbuild -bi kernel-4.1.0.spec
> > on an Ubuntu system, notice that on Ubuntu, there are already a
> > 'build' and 'source' symlink before the ln -sf commands are issued,
> > CentOS however doesn't have those links on the same step.
> > user@build-ubuntu:/srv/user/rpmbuild$ rpmbuild -bi
> > SPECS/kernel-4.1.0.spec
> That is outside the realm of "make rpm".
> I assume kernel-4.1.0.spec was a copy, somehow made, of kernel.spec as
> was created by "make rpm". Does it matter, for the issue you ran into,
> whether "make rpm" or "rpmbuild -bb SPECS/kernel.spec" is involved?

During "make rpm", I copied the tar.gz and kernel.spec files, so I could debug.
The reason for using "rpmbuild -bb" instead is that it goes faster to get to the same point than
"make rpm". But I can reproduce the issue both with "make rpm" and "rpmbuild -bb".

> > user@build-ubuntu:/srv/user/rpmbuild/BUILDROOT/kernel-4.1.0-1.x86_64/lib/modules/4.1.0$ ls -gG total 64
> > lrwxrwxrwx 1 35 Jul 6 18:56 build -> /srv/user/rpmbuild/BUILD/kernel-4.1.0
> > [...]
> > lrwxrwxrwx 1 35 Jul 6 19:00 source -> /srv/user/rpmbuild/BUILD/kernel-4.1.0
> These two links are, I think, generated in this snippet from the main
> Makefile:
> _modinst_:
> @rm -rf $(MODLIB)/kernel
> @rm -f $(MODLIB)/source
> @mkdir -p $(MODLIB)/kernel
> @ln -s `cd $(srctree) && /bin/pwd` $(MODLIB)/source
> @if [ ! $(objtree) -ef $(MODLIB)/build ]; then \
> rm -f $(MODLIB)/build ; \
> ln -s $(CURDIR) $(MODLIB)/build ; \
> fi
> @cp -f $(objtree)/modules.order $(MODLIB)/
> @cp -f $(objtree)/modules.builtin $(MODLIB)/
> $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modinst
> I wonder why you don't see similar links when building on CentOS. I saw
> similar links in rpm's BUILDROOT when building on Fedora 22.

I just did my test on Fedora 22.
As I stated in the example email, you have to comment out or remove:
ln -sf /usr/src/kernels/4.1.0 build
ln -sf /usr/src/kernels/4.1.0 source
from the %install section of the .spec file.

Without them, you'll notice that on Fedora 22 Server, when compiling the kernel, the "build" and "source" links aren't there.
That's what those two lines in the spec file are for, to add the "build" and "source" symlinks.
On an Ubuntu system however, the links are there, so the ln -sf lines will not overwrite the existing ones, instead there will be created a new symlink inside the directory that build and source points to named "4.1.0" pointing to /usr/src/kernels/4.1.0 (look at the example mail).
Changing the lines:
ln -sf /usr/src/kernels/4.1.0 build
ln -sf /usr/src/kernels/4.1.0 source
to:
ln -sfT /usr/src/kernels/4.1.0 build
ln -sfT /usr/src/kernels/4.1.0 source
Will change the spec script to overwrite the existing links on the Ubuntu type systems so it will be correct.

Espen

2015-08-19 15:14:55

by Michal Marek

[permalink] [raw]
Subject: Re: [PATCH, resend] build: fix broken kernel RPM source symlink

On 2015-06-30 13:47, Espen Carlsen wrote:
> Fix the 'rpm-pkg' makefile target to always generate the correct
> /usr/src/kernel/<ver> symlink; this fails on non-RPM-native systems
> eg Ubuntu.
>
> On a non-RPM-native system, the symlink created by rpmbuild points to
> the source tree, so the ln -sf commands to overwrite build and source will
> create a new link inside the directory pointed to by the build and source
> symlinks. This will break the -devel.rpm, as the build and source symlinks
> will point to non existing directories after installing them.

Which version of rpm do you have installed? $RPM_BUILD_ROOT should be
deleted and created empty by rpmbuild. If you have stale files in
$RPM_BUILD_ROOT, you will likely have bigger problem than this.

Michal