Hello,
Last year there was a change to how the kernel-headers package is built, and unfortunately that change made it so that changes to the kernel's buildid variable do not carryover to the the kernel-header's build. While I recognize that this is problem that only affects a small number of people, it would be nice to see this fixed.
I'm attaching a small patch which fixes this for my use case, and while I think it is a generic solution, I can't say I've spent enough time looking at it to say for certain. I'm putting it out here as a way to help describe the problem as well as one possible solution. If you have a different/better approach that's fine with me, I just want to see the buildid reflected in the kernel-header package build so I can drop this patch from my build process :)
On Wed, Aug 21, 2019 at 2:47 PM Paul Moore paul@paul-moore.com wrote:
Hello,
Last year there was a change to how the kernel-headers package is built, and unfortunately that change made it so that changes to the kernel's buildid variable do not carryover to the the kernel-header's build. While I recognize that this is problem that only affects a small number of people, it would be nice to see this fixed.
I'm attaching a small patch which fixes this for my use case, and
The list strips attachments. Can you send it inline?
josh
while I think it is a generic solution, I can't say I've spent enough time looking at it to say for certain. I'm putting it out here as a way to help describe the problem as well as one possible solution. If you have a different/better approach that's fine with me, I just want to see the buildid reflected in the kernel-header package build so I can drop this patch from my build process :)
-- paul moore www.paul-moore.com _______________________________________________ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
On Wed, 2019-08-21 at 14:48 -0400, Josh Boyer wrote:
On Wed, Aug 21, 2019 at 2:47 PM Paul Moore paul@paul-moore.com wrote:
Hello,
Last year there was a change to how the kernel-headers package is built, and unfortunately that change made it so that changes to the kernel's buildid variable do not carryover to the the kernel- header's build. While I recognize that this is problem that only affects a small number of people, it would be nice to see this fixed.
I'm attaching a small patch which fixes this for my use case, and
The list strips attachments. Can you send it inline?
Sorry about that, a little birdie warned me against sending patches inline to this list (something about whitespace mangling), but the patch is pasted below. Also, in the case there are issues, I put a copy of the patch here:
* https://drop.paul-moore.com/14.aTxy/07-headers_buildid.patch
--- scripts/create_headers_tarball.sh.orig 2019-05-06 17:50:49.533846042 -0400 +++ scripts/create_headers_tarball.sh 2019-05-06 17:57:54.259359305 -0400 @@ -26,13 +26,14 @@ BASE=`grep "%define base_sublevel" kerne STABLE=`grep "%define stable_update" kernel.spec| cut -d ' ' -f 3` RC=`grep "%global rcrev" kernel.spec| cut -d ' ' -f 3` GITREV=`grep "%define gitrev" kernel.spec| cut -d ' ' -f 3` +BUILDID=`grep "^%define buildid" kernel.spec| cut -d ' ' -f 3` if [ $RELEASED -eq 0 ]; then cd kernel-$MAJORVER.$BASE.fc?? NEWBASE=$(($BASE+1)) - KVER=$MAJORVER.$NEWBASE.0-0.rc$RC.git$GITREV.$BASERELEASE - cd linux-$MAJORVER.$NEWBASE.0-0.rc$RC.git$GITREV.$BASERELEASE.fc*/ + KVER=$MAJORVER.$NEWBASE.0-0.rc$RC.git$GITREV.$BASERELEASE$BUILDID + cd linux-$MAJORVER.$NEWBASE.0-0.rc$RC.git$GITREV.$BASERELEASE$BUILDID.fc*/ else - cd kernel-$MAJORVER.$BASE.fc??/linux-$MAJORVER.$BASE.$STABLE-$BASERELEASE.fc*/ + cd kernel-$MAJORVER.$BASE.fc??/linux-$MAJORVER.$BASE.$STABLE-$BASERELEASE$BUILDID.fc*/ KVER=$MAJORVER.$BASE.$STABLE-$BASERELEASE fi
@@ -64,6 +65,7 @@ BASERELEASE=$(($BASERELEASE-1)) BASERELEASE=$BASERELEASE perl -p -i -e 's|%global baserelease.*|%global baserelease $ENV{'BASERELEASE'}|' kernel-headers.spec
if [ $RELEASED -eq 0 ]; then + [ -n $BUILDID ] && sed -i -e 's/^# define buildid .local/%define buildid '$BUILDID'/' kernel-headers.spec RC=$RC perl -p -i -e 's|%global rcrev.*|%global rcrev $ENV{'RC'}|' kernel-headers.spec GITREV=$GITREV perl -p -i -e 's|%define gitrev.*|%define gitrev $ENV{'GITREV'}|' kernel-headers.spec rpmdev-bumpspec -c "Linux v$MAJORVER.$NEWBASE-rc$RC.git$GITREV" kernel-headers.spec
On Wed, Aug 21, 2019 at 3:30 PM Paul Moore paul@paul-moore.com wrote:
On Wed, 2019-08-21 at 14:48 -0400, Josh Boyer wrote:
On Wed, Aug 21, 2019 at 2:47 PM Paul Moore paul@paul-moore.com wrote:
Hello,
Last year there was a change to how the kernel-headers package is built, and unfortunately that change made it so that changes to the kernel's buildid variable do not carryover to the the kernel- header's build. While I recognize that this is problem that only affects a small number of people, it would be nice to see this fixed.
I'm attaching a small patch which fixes this for my use case, and
The list strips attachments. Can you send it inline?
Sorry about that, a little birdie warned me against sending patches inline to this list (something about whitespace mangling), but the patch is pasted below. Also, in the case there are issues, I put a copy of the patch here:
Any thoughts on fixing this problem?
--- scripts/create_headers_tarball.sh.orig 2019-05-06 17:50:49.533846042 -0400 +++ scripts/create_headers_tarball.sh 2019-05-06 17:57:54.259359305 -0400 @@ -26,13 +26,14 @@ BASE=`grep "%define base_sublevel" kerne STABLE=`grep "%define stable_update" kernel.spec| cut -d ' ' -f 3` RC=`grep "%global rcrev" kernel.spec| cut -d ' ' -f 3` GITREV=`grep "%define gitrev" kernel.spec| cut -d ' ' -f 3` +BUILDID=`grep "^%define buildid" kernel.spec| cut -d ' ' -f 3` if [ $RELEASED -eq 0 ]; then cd kernel-$MAJORVER.$BASE.fc?? NEWBASE=$(($BASE+1))
KVER=$MAJORVER.$NEWBASE.0-0.rc$RC.git$GITREV.$BASERELEASEcd linux-$MAJORVER.$NEWBASE.0-0.rc$RC.git$GITREV.$BASERELEASE.fc*/
KVER=$MAJORVER.$NEWBASE.0-0.rc$RC.git$GITREV.$BASERELEASE$BUILDIDcd linux-$MAJORVER.$NEWBASE.0-0.rc$RC.git$GITREV.$BASERELEASE$BUILDID.fc*/else
cd kernel-$MAJORVER.$BASE.fc??/linux-$MAJORVER.$BASE.$STABLE-$BASERELEASE.fc*/
cd kernel-$MAJORVER.$BASE.fc??/linux-$MAJORVER.$BASE.$STABLE-$BASERELEASE$BUILDID.fc*/ KVER=$MAJORVER.$BASE.$STABLE-$BASERELEASEfi
@@ -64,6 +65,7 @@ BASERELEASE=$(($BASERELEASE-1)) BASERELEASE=$BASERELEASE perl -p -i -e 's|%global baserelease.*|%global baserelease $ENV{'BASERELEASE'}|' kernel-headers.spec
if [ $RELEASED -eq 0 ]; then
[ -n $BUILDID ] && sed -i -e 's/^# define buildid .local/%define buildid '$BUILDID'/' kernel-headers.spec RC=$RC perl -p -i -e 's|%global rcrev.*|%global rcrev $ENV{'RC'}|' kernel-headers.spec GITREV=$GITREV perl -p -i -e 's|%define gitrev.*|%define gitrev $ENV{'GITREV'}|' kernel-headers.spec rpmdev-bumpspec -c "Linux v$MAJORVER.$NEWBASE-rc$RC.git$GITREV" kernel-headers.spec
On 9/26/19 11:44 AM, Paul Moore wrote:
On Wed, Aug 21, 2019 at 3:30 PM Paul Moore paul@paul-moore.com wrote:
On Wed, 2019-08-21 at 14:48 -0400, Josh Boyer wrote:
On Wed, Aug 21, 2019 at 2:47 PM Paul Moore paul@paul-moore.com wrote:
Hello,
Last year there was a change to how the kernel-headers package is built, and unfortunately that change made it so that changes to the kernel's buildid variable do not carryover to the the kernel- header's build. While I recognize that this is problem that only affects a small number of people, it would be nice to see this fixed.
I'm attaching a small patch which fixes this for my use case, and
The list strips attachments. Can you send it inline?
Sorry about that, a little birdie warned me against sending patches inline to this list (something about whitespace mangling), but the patch is pasted below. Also, in the case there are issues, I put a copy of the patch here:
Any thoughts on fixing this problem?
Thanks for the reminder this completely slipped my mind. I put this into rawhide and we can test it for a few releases of that. If it works, we can also bring it into the stable releases.
--- scripts/create_headers_tarball.sh.orig 2019-05-06 17:50:49.533846042 -0400 +++ scripts/create_headers_tarball.sh 2019-05-06 17:57:54.259359305 -0400 @@ -26,13 +26,14 @@ BASE=`grep "%define base_sublevel" kerne STABLE=`grep "%define stable_update" kernel.spec| cut -d ' ' -f 3` RC=`grep "%global rcrev" kernel.spec| cut -d ' ' -f 3` GITREV=`grep "%define gitrev" kernel.spec| cut -d ' ' -f 3` +BUILDID=`grep "^%define buildid" kernel.spec| cut -d ' ' -f 3` if [ $RELEASED -eq 0 ]; then cd kernel-$MAJORVER.$BASE.fc?? NEWBASE=$(($BASE+1))
KVER=$MAJORVER.$NEWBASE.0-0.rc$RC.git$GITREV.$BASERELEASEcd linux-$MAJORVER.$NEWBASE.0-0.rc$RC.git$GITREV.$BASERELEASE.fc*/
KVER=$MAJORVER.$NEWBASE.0-0.rc$RC.git$GITREV.$BASERELEASE$BUILDIDcd linux-$MAJORVER.$NEWBASE.0-0.rc$RC.git$GITREV.$BASERELEASE$BUILDID.fc*/
cd kernel-$MAJORVER.$BASE.fc??/linux-$MAJORVER.$BASE.$STABLE-$BASERELEASE.fc*/
cd kernel-$MAJORVER.$BASE.fc??/linux-$MAJORVER.$BASE.$STABLE-$BASERELEASE$BUILDID.fc*/ KVER=$MAJORVER.$BASE.$STABLE-$BASERELEASE@@ -64,6 +65,7 @@ BASERELEASE=$(($BASERELEASE-1)) BASERELEASE=$BASERELEASE perl -p -i -e 's|%global baserelease.*|%global baserelease $ENV{'BASERELEASE'}|' kernel-headers.spec
if [ $RELEASED -eq 0 ]; then
[ -n $BUILDID ] && sed -i -e 's/^# define buildid .local/%define buildid '$BUILDID'/' kernel-headers.spec RC=$RC perl -p -i -e 's|%global rcrev.*|%global rcrev $ENV{'RC'}|' kernel-headers.spec GITREV=$GITREV perl -p -i -e 's|%define gitrev.*|%define gitrev $ENV{'GITREV'}|' kernel-headers.spec rpmdev-bumpspec -c "Linux v$MAJORVER.$NEWBASE-rc$RC.git$GITREV" kernel-headers.spec
On Mon, Sep 30, 2019 at 7:23 AM Laura Abbott labbott@redhat.com wrote:
On 9/26/19 11:44 AM, Paul Moore wrote:
On Wed, Aug 21, 2019 at 3:30 PM Paul Moore paul@paul-moore.com wrote:
On Wed, 2019-08-21 at 14:48 -0400, Josh Boyer wrote:
On Wed, Aug 21, 2019 at 2:47 PM Paul Moore paul@paul-moore.com wrote:
Hello,
Last year there was a change to how the kernel-headers package is built, and unfortunately that change made it so that changes to the kernel's buildid variable do not carryover to the the kernel- header's build. While I recognize that this is problem that only affects a small number of people, it would be nice to see this fixed.
I'm attaching a small patch which fixes this for my use case, and
The list strips attachments. Can you send it inline?
Sorry about that, a little birdie warned me against sending patches inline to this list (something about whitespace mangling), but the patch is pasted below. Also, in the case there are issues, I put a copy of the patch here:
Any thoughts on fixing this problem?
Thanks for the reminder this completely slipped my mind. I put this into rawhide and we can test it for a few releases of that. If it works, we can also bring it into the stable releases.
Sounds good to me - thanks!
On Mon, Sep 30, 2019 at 7:23 AM Laura Abbott labbott@redhat.com wrote:
On 9/26/19 11:44 AM, Paul Moore wrote:
On Wed, Aug 21, 2019 at 3:30 PM Paul Moore paul@paul-moore.com wrote:
On Wed, 2019-08-21 at 14:48 -0400, Josh Boyer wrote:
On Wed, Aug 21, 2019 at 2:47 PM Paul Moore paul@paul-moore.com wrote:
Hello,
Last year there was a change to how the kernel-headers package is built, and unfortunately that change made it so that changes to the kernel's buildid variable do not carryover to the the kernel- header's build. While I recognize that this is problem that only affects a small number of people, it would be nice to see this fixed.
I'm attaching a small patch which fixes this for my use case, and
The list strips attachments. Can you send it inline?
Sorry about that, a little birdie warned me against sending patches inline to this list (something about whitespace mangling), but the patch is pasted below. Also, in the case there are issues, I put a copy of the patch here:
Any thoughts on fixing this problem?
Thanks for the reminder this completely slipped my mind. I put this into rawhide and we can test it for a few releases of that. If it works, we can also bring it into the stable releases.
For the record, the Rawhide builds have been working fine for me (modified buildid) this past week; thanks again for updating the scripts.
kernel@lists.fedoraproject.org
-
Josh Boyer -
Laura Abbott -
Paul Moore