FS#43885 - [linux] makepkg --pkg linux-headers fails

Attached to Project: Arch Linux
Opened by Mikael Eriksson (miffe) - Thursday, 19 February 2015, 11:11 GMT
Last edited by Doug Newgard (Scimmia) - Wednesday, 20 July 2016, 13:19 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas Bächler (brain0)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Building just the linux-headers package using "makepkg --pkg linux-headers" fails with:

==> Starting package_linux-headers()...
cp: cannot stat 'arch//Makefile': No such file or directory
==> ERROR: A failure occurred in package_linux-headers().

The problem is the KARCH variable which is set in _package() but used in _package-headers(), but since _package() isn't run when only building the headers it fails.

Attaching a patch to move the KARCH variable to global scope.
This task depends upon

Closed by  Doug Newgard (Scimmia)
Wednesday, 20 July 2016, 13:19 GMT
Reason for closing:  None
Additional comments about closing:  --pkg option has been removed from makepkg
Comment by Frans-Willem Hardijzer (Frans-Willem) - Tuesday, 30 June 2015, 19:35 GMT
While this is not a big deal for the core packages, since they are rarely compiled from source anyway (especially the headers package), it does turn out to be rather inconvenient for packages based on this, like the linux-vfio AUR package.
On my system Yaourt is currently unable to properly upgrade the linux-vfio-headers package because of this bug, and as a result none of my DKMS modules will compile for it.

This seems like an easy fix, is there any reason it's been on the backlog since February ?
Comment by Mark Blakeney (bulletmark) - Thursday, 02 July 2015, 10:47 GMT
I used yaourt to build linux-xps13-alt 4.0.5-1 fine last week, but when trying to update to 4.0.6-1 and after many hours of building I got the same error as reported here. Last week I had also used yaourt to install linux-mainline 4.1rc7, but then trying to update to 4.1 today (from aur4), it failed also with this same error. Seems odd this bug is 5 months old but I am only seeing this bug in the last few days?
Comment by Mark Blakeney (bulletmark) - Thursday, 02 July 2015, 10:52 GMT
I'll also add that I am sure when I installed those first successful kernels the total build/install time was about 2 hours. However with the 2 failed cases it seems to install and install the main kernel package which takes about 2 hours, then it builds the kernel again for another 2 hours for the -docs package, then another 2 hours for the -headers package which is the one that fails. Should the -docs and -headers package require their own 2 hour kernel rebuilds? Doesn't seem right.
Comment by Frans-Willem Hardijzer (Frans-Willem) - Thursday, 02 July 2015, 11:55 GMT
@Mark: I suspect that Yaourt might be currently building split packages separately somehow. That's probably also a bug, but doesn't take away the fact that it brings this bug closer to the surface.
Comment by Mark Blakeney (bulletmark) - Thursday, 02 July 2015, 12:04 GMT
Sorry, you mean a new bug in yaourt? Or a new bug in the ABS when used to build these kernel packages?
Comment by Frans-Willem Hardijzer (Frans-Willem) - Thursday, 02 July 2015, 12:36 GMT
I'm not entirely sure it would classify as a bug, but I do think it's undesirable for yaourt to build all those split packages seperately instead of just building the entire thing once :/
Comment by Mark Blakeney (bulletmark) - Thursday, 02 July 2015, 22:49 GMT
OK thanks. I found an issue about how yaourt deals with split packages at https://github.com/archlinuxfr/yaourt/issues/105 and have added a comment there.
Comment by Frans-Willem Hardijzer (Frans-Willem) - Sunday, 05 July 2015, 12:49 GMT
I've tried the patch in the original bugreport, and although it builds, there are still some variables missing (namely _kernvar) in linux-headers and linux-docs, making the files end up in the wrong places.
Attached is my attempt. Basically it moves the variables definitions of _package to _common_package, and in the loop at the end that binds package_* to _package_* I added a call to _common_package for all.

I've tested compiling linux-headers on it's own, and the package builds, and the files end up in the correct place, finally :)

I hope this is enough to get this resolved quickly.

Loading...