Message ID | 20231219181957.1449958-1-masahiroy@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-5800-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:24d3:b0:fb:cd0c:d3e with SMTP id r19csp2140468dyi; Tue, 19 Dec 2023 10:29:17 -0800 (PST) X-Google-Smtp-Source: AGHT+IGVKzdW+olBqKPu3vdXbIhTyHVnPNZQxRSUnd5p+nFMRg5IfQUcFntzIH4H2+PdS57cHT25 X-Received: by 2002:a17:903:244e:b0:1d3:d3a6:1549 with SMTP id l14-20020a170903244e00b001d3d3a61549mr2581993pls.57.1703010556954; Tue, 19 Dec 2023 10:29:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703010556; cv=none; d=google.com; s=arc-20160816; b=vZ+jR0N4WdtZmXtlCA2j8+qT6M7SGD3sMYJiyTqv6pZBDbvCxWvPH5V0LpGJqy+/bm /4THf5XB9OywhLPGxIqT8sUcCVNGmB03MBUfHITQGn6QRmewPsEgkVDpwE9oqEjW0jjq v6oe+/aj5WIAcFbUq7G8Io0xg2uoeZviLAHUkLkTQ0iJsEqkuuQMAI6yowezhQyL7bdk KV86hmHEarqXAVP+8sN+icIullyrh7ioZ+0yKEOjSW/VZLVGiYM00mzYLNwQKE1PkDT6 Q3D49MDlmV5WyxWUICZYyPl/yhSA5IzkjRvHEygukjtXwRBiWoqmYNZp+v1MCDzCFT6f F2ww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=fgyNfYSD14MaGL4bNdiVkx2f/JLHfQryf+ry4uE7wyQ=; fh=5gYN4msaJmwnN8mGpibv8VZnTy0MtvGQcf5D09XpoaQ=; b=l5crgroQ1YhlL49CFjOthrABRj+2JtoMnwLn8L4qrPp8wbJgiFU+tC6Osv9M+XfOg6 PSnH9UYIpicL7yKVOVS5LBW7oO7NuKKzMIr/6s2AZC3z6EHx13c6MFR9dCGJd/SfzhYP rh6w/TH44CnIQ1MxY+8pn/kzvpZzBl8QPD1ytmCYCb0R/b0Et0FMjcfBgz/tu9A+BCUF w+Ap9sWP0NZYSHiJ0w1SKk0vYgQKnd3tvbumzu7Cb17mfSnjqR7Q5zX1IO2qbM4Bdsub yGHUN4mjNsBFFjb4AeykazQA6skaREFIj8wwAa7GoEqrnb305a+CZsx73ckUcojJP2ZC UipA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=qYF1DQSO; spf=pass (google.com: domain of linux-kernel+bounces-5800-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-5800-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id t6-20020a1709028c8600b001d08f1a5c70si9115327plo.405.2023.12.19.10.29.16 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Dec 2023 10:29:16 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-5800-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=qYF1DQSO; spf=pass (google.com: domain of linux-kernel+bounces-5800-ouuuleilei=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-5800-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id A08C7B25139 for <ouuuleilei@gmail.com>; Tue, 19 Dec 2023 18:20:26 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B391A38FAD; Tue, 19 Dec 2023 18:20:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qYF1DQSO" X-Original-To: linux-kernel@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E23EF37D22; Tue, 19 Dec 2023 18:20:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 177D0C433C8; Tue, 19 Dec 2023 18:20:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1703010003; bh=aInprk0ngpVeNnqzMh3MIxqFI0iItoCxCcQKP9eY+0g=; h=From:To:Cc:Subject:Date:From; b=qYF1DQSOUwWbonEZuQnUedchL1AA/rl6qHM2alJs8EwfCOZZWCbd89Y/ZY94Bp+fF UFk0cuWkuNhE6dXiikjazDtGwu7SV+flwC63uGVnlX25OI9qRt2D62SSgqo71dILjx vby74RHSBwqsvMItLWyOZwvI9e0Pw23mG8W8hnGGYv4YvPtYh4cqycU9y/kLazRQZe KFzYAnIiO9sHI1Zht7+kBno+E9F4QNfGe12UW8RD6yvV4wKkcGTnZto9mqkM9Cc2YS XoDb2rPX0ZAC9+CoKmPcOvnFhiJmDEgSdR8dVen6l5iS6kIpNpwWDHORbXuPbecXt7 L32q1BN8wU5WA== From: Masahiro Yamada <masahiroy@kernel.org> To: linux-kbuild@vger.kernel.org Cc: Ben Hutchings <ben@decadent.org.uk>, Masahiro Yamada <masahiroy@kernel.org>, Nathan Chancellor <nathan@kernel.org>, Nick Desaulniers <ndesaulniers@google.com>, Nicolas Schier <nicolas@fjasle.eu>, linux-kernel@vger.kernel.org Subject: [PATCH 1/3] kbuild: deb-pkg: do not query DEB_HOST_MULTIARCH Date: Wed, 20 Dec 2023 03:19:55 +0900 Message-Id: <20231219181957.1449958-1-masahiroy@kernel.org> X-Mailer: git-send-email 2.40.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1785735998263558321 X-GMAIL-MSGID: 1785735998263558321 |
Series |
[1/3] kbuild: deb-pkg: do not query DEB_HOST_MULTIARCH
|
|
Commit Message
Masahiro Yamada
Dec. 19, 2023, 6:19 p.m. UTC
Since commit 491b146d4c13 ("kbuild: builddeb: Eliminate debian/arch
use"), the direct execution of debian/rules fails with:
dpkg-architecture: error: unknown option 'DEB_HOST_MULTIARCH'
I am not sure how important to support such a use case, but at least
the current code:
dpkg-architecture -a$DEB_HOST_ARCH -qDEB_HOST_MULTIARCH
... looks weird because:
- For this code to work correctly, DEB_HOST_ARCH must be defined.
In this case, DEB_HOST_MULTIARCH is likely defined, so there is no
need to query DEB_HOST_MULTIARCH in the first place. This is likely
the case where the package build was initiated by dpkg-buildpackage.
- If DEB_HOST_MULTIARCH is undefined, DEB_HOST_ARCH is likely undefined.
So, you cannot query DEB_HOST_MULTIARCH in this way. This is mostly
the case where debian/rules is directly executed.
If we want to run debian/rules directly, we can revert 491b146d4c13 or
add code to remember DEB_HOST_MULTIARCH, but I chose to remove the
useless code for now.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
---
scripts/package/builddeb | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Comments
On Wed, Dec 20, 2023 at 03:19:55AM +0900, Masahiro Yamada wrote: > Since commit 491b146d4c13 ("kbuild: builddeb: Eliminate debian/arch > use"), the direct execution of debian/rules fails with: > > dpkg-architecture: error: unknown option 'DEB_HOST_MULTIARCH' > > I am not sure how important to support such a use case, but at least > the current code: > > dpkg-architecture -a$DEB_HOST_ARCH -qDEB_HOST_MULTIARCH > > ... looks weird because: > > - For this code to work correctly, DEB_HOST_ARCH must be defined. > In this case, DEB_HOST_MULTIARCH is likely defined, so there is no > need to query DEB_HOST_MULTIARCH in the first place. This is likely > the case where the package build was initiated by dpkg-buildpackage. > > - If DEB_HOST_MULTIARCH is undefined, DEB_HOST_ARCH is likely undefined. > So, you cannot query DEB_HOST_MULTIARCH in this way. This is mostly > the case where debian/rules is directly executed. > > If we want to run debian/rules directly, we can revert 491b146d4c13 or > add code to remember DEB_HOST_MULTIARCH, but I chose to remove the > useless code for now. > > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> > --- thanks. Fixing the non-functional things is obviously a good thing. Reviewed-by: Nicolas Schier <n.schier@avm.de> Iff we'd like to be able to call debian/rules directly, do we really have to remember DEB_HOST_MULTIARCH, or just DEB_HOST_ARCH? In the latter case, might this be a sufficient way to allow calling debian/rules again? diff --git a/scripts/package/debian/rules b/scripts/package/debian/rules index 3dafa9496c63..e3e0001e7556 100755 --- a/scripts/package/debian/rules +++ b/scripts/package/debian/rules @@ -3,7 +3,9 @@ include debian/rules.vars -srctree ?= . +DEB_HOST_ARCH ?= $(shell cat debian/arch) + +srctree ?= $(or $(wildcard source), .) ifneq (,$(filter-out parallel=1,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))) NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) ... but the more I think about it, I am not convinced that we want to use the debian/arch file. Actually I think it would be nice if we strive for an architecture independent source package instead of engraving the architecture even more. Nevertheless, your patch looks good to me. Kind regards, Nicolas > > scripts/package/builddeb | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/scripts/package/builddeb b/scripts/package/builddeb > index 2fe51e6919da..2eb4910f0ef3 100755 > --- a/scripts/package/builddeb > +++ b/scripts/package/builddeb > @@ -171,9 +171,8 @@ install_libc_headers () { > > # move asm headers to /usr/include/<libc-machine>/asm to match the structure > # used by Debian-based distros (to support multi-arch) > - host_arch=$(dpkg-architecture -a$DEB_HOST_ARCH -qDEB_HOST_MULTIARCH) > - mkdir $pdir/usr/include/$host_arch > - mv $pdir/usr/include/asm $pdir/usr/include/$host_arch/ > + mkdir "$pdir/usr/include/${DEB_HOST_MULTIARCH}" > + mv "$pdir/usr/include/asm" "$pdir/usr/include/${DEB_HOST_MULTIARCH}" > } > > rm -f debian/files > -- > 2.40.1 >
On Fri, Dec 22, 2023 at 11:30 PM Nicolas Schier <n.schier@avm.de> wrote: > > On Wed, Dec 20, 2023 at 03:19:55AM +0900, Masahiro Yamada wrote: > > Since commit 491b146d4c13 ("kbuild: builddeb: Eliminate debian/arch > > use"), the direct execution of debian/rules fails with: > > > > dpkg-architecture: error: unknown option 'DEB_HOST_MULTIARCH' > > > > I am not sure how important to support such a use case, but at least > > the current code: > > > > dpkg-architecture -a$DEB_HOST_ARCH -qDEB_HOST_MULTIARCH > > > > ... looks weird because: > > > > - For this code to work correctly, DEB_HOST_ARCH must be defined. > > In this case, DEB_HOST_MULTIARCH is likely defined, so there is no > > need to query DEB_HOST_MULTIARCH in the first place. This is likely > > the case where the package build was initiated by dpkg-buildpackage. > > > > - If DEB_HOST_MULTIARCH is undefined, DEB_HOST_ARCH is likely undefined. > > So, you cannot query DEB_HOST_MULTIARCH in this way. This is mostly > > the case where debian/rules is directly executed. > > > > If we want to run debian/rules directly, we can revert 491b146d4c13 or > > add code to remember DEB_HOST_MULTIARCH, but I chose to remove the > > useless code for now. > > > > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> > > --- > > thanks. Fixing the non-functional things is obviously a good thing. > > Reviewed-by: Nicolas Schier <n.schier@avm.de> > > > Iff we'd like to be able to call debian/rules directly, do we really > have to remember DEB_HOST_MULTIARCH, or just DEB_HOST_ARCH? Theoretically, if we know DEB_HOST_ARCH, other DEB_HOST_* can be derived. scripts/package/deb-build-option needs to know more DEB_* variables. DEB_HOST_ARCH DEB_BUILD_ARCH DEB_HOST_GNU_TYPE > > In the latter case, might this be a sufficient way to allow calling > debian/rules again? Not perfectly. scripts/package/deb-build-option does not work as intended. > > diff --git a/scripts/package/debian/rules b/scripts/package/debian/rules > index 3dafa9496c63..e3e0001e7556 100755 > --- a/scripts/package/debian/rules > +++ b/scripts/package/debian/rules > @@ -3,7 +3,9 @@ > > include debian/rules.vars > > -srctree ?= . > +DEB_HOST_ARCH ?= $(shell cat debian/arch) > + > +srctree ?= $(or $(wildcard source), .) > > ifneq (,$(filter-out parallel=1,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))) > NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) > > > ... but the more I think about it, I am not convinced that we want to > use the debian/arch file. Actually I think it would be nice if we > strive for an architecture independent source package instead of > engraving the architecture even more. The source package _is_ arch-independent, can be built for a single architecture because the source package for upstream contains the .config, which is configured for a particular architecture. > > Nevertheless, your patch looks good to me. > > Kind regards, > Nicolas > > > > > > > scripts/package/builddeb | 5 ++--- > > 1 file changed, 2 insertions(+), 3 deletions(-) > > > > diff --git a/scripts/package/builddeb b/scripts/package/builddeb > > index 2fe51e6919da..2eb4910f0ef3 100755 > > --- a/scripts/package/builddeb > > +++ b/scripts/package/builddeb > > @@ -171,9 +171,8 @@ install_libc_headers () { > > > > # move asm headers to /usr/include/<libc-machine>/asm to match the structure > > # used by Debian-based distros (to support multi-arch) > > - host_arch=$(dpkg-architecture -a$DEB_HOST_ARCH -qDEB_HOST_MULTIARCH) > > - mkdir $pdir/usr/include/$host_arch > > - mv $pdir/usr/include/asm $pdir/usr/include/$host_arch/ > > + mkdir "$pdir/usr/include/${DEB_HOST_MULTIARCH}" > > + mv "$pdir/usr/include/asm" "$pdir/usr/include/${DEB_HOST_MULTIARCH}" > > } > > > > rm -f debian/files > > -- > > 2.40.1 > >
diff --git a/scripts/package/builddeb b/scripts/package/builddeb index 2fe51e6919da..2eb4910f0ef3 100755 --- a/scripts/package/builddeb +++ b/scripts/package/builddeb @@ -171,9 +171,8 @@ install_libc_headers () { # move asm headers to /usr/include/<libc-machine>/asm to match the structure # used by Debian-based distros (to support multi-arch) - host_arch=$(dpkg-architecture -a$DEB_HOST_ARCH -qDEB_HOST_MULTIARCH) - mkdir $pdir/usr/include/$host_arch - mv $pdir/usr/include/asm $pdir/usr/include/$host_arch/ + mkdir "$pdir/usr/include/${DEB_HOST_MULTIARCH}" + mv "$pdir/usr/include/asm" "$pdir/usr/include/${DEB_HOST_MULTIARCH}" } rm -f debian/files