mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nathan Chancellor <nathan@kernel.org>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: "Thomas Weißschuh" <linux@weissschuh.net>,
	"Nicolas Schier" <nicolas@fjasle.eu>,
	"Jan Alexander Steffens (heftig)" <heftig@archlinux.org>,
	"Christian Heusel" <christian@heusel.eu>,
	linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org
Subject: Re: [PATCH v7] kbuild: add script and target to generate pacman package
Date: Sun, 21 Jul 2024 05:11:09 -0700	[thread overview]
Message-ID: <20240721121109.GA3599565@thelio-3990X> (raw)
In-Reply-To: <CAK7LNARj9fxm_3h=7g4PLbLDHXNUQrRu8iOQ4sZdx8Ag3YS9sA@mail.gmail.com>

Hi Masahiro,

On Sun, Jul 21, 2024 at 03:58:49PM +0900, Masahiro Yamada wrote:
> On Sun, Jul 21, 2024 at 12:32 PM Nathan Chancellor <nathan@kernel.org> wrote:
> > On Sat, Jul 20, 2024 at 11:18:12AM +0200, Thomas Weißschuh wrote:
> > > pacman is the package manager used by Arch Linux and its derivates.
> > > Creating native packages from the kernel tree has multiple advantages:
> > >
> > > * The package triggers the correct hooks for initramfs generation and
> > >   bootloader configuration
> > > * Uninstallation is complete and also invokes the relevant hooks
> > > * New UAPI headers can be installed without any manual bookkeeping
> > >
> > > The PKGBUILD file is a modified version of the one used for the
> > > downstream Arch Linux "linux" package.
> > > Extra steps that should not be necessary for a development kernel have
> > > been removed and an UAPI header package has been added.
> > >
> > > Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> > > ---
> >
> > I think this looks really solid now, thanks again for the PACMAN_PKGBASE
> > addition.
> >
> > I tested building Arch Linux's configuration for x86_64 and booting it
> > in a VM. I built Fedora's configuration for aarch64 just to test the
> > cross building aspect and making sure the result of various bits that we
> > added that would not affect x86 (such as the dtb installation) looked
> > reasonable.
> >
> > Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> > Tested-by: Nathan Chancellor <nathan@kernel.org>
> 
> I believe this is a separate issue, but
> Debian/Ubuntu provides a 'makepkg' package, which fails
> with 'User defined signal 1' error.
> 
> After 'sudo apt install makepkg',
> 
> masahiro@zoe:~/ref/linux-next((HEAD detached from origin/master))$ cat
> /etc/os-release
> PRETTY_NAME="Ubuntu 24.04 LTS"
> NAME="Ubuntu"
> VERSION_ID="24.04"
> VERSION="24.04 LTS (Noble Numbat)"
> VERSION_CODENAME=noble
> ID=ubuntu
> ID_LIKE=debian
> HOME_URL="https://www.ubuntu.com/"
> SUPPORT_URL="https://help.ubuntu.com/"
> BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
> PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
> UBUNTU_CODENAME=noble
> LOGO=ubuntu-logo
> masahiro@zoe:~/ref/linux-next((HEAD detached from origin/master))$
> makepkg --version
> makepkg (pacman) 6.0.2
> Copyright (c) 2006-2021 Pacman Development Team <pacman-dev@archlinux.org>.
> Copyright (C) 2002-2006 Judd Vinet <jvinet@zeroflux.org>.
> 
> This is free software; see the source for copying conditions.
> There is NO WARRANTY, to the extent permitted by law.
> masahiro@zoe:~/ref/linux-next((HEAD detached from origin/master))$ git
> log --oneline -2
> 5dcaebb67ad9 (HEAD) kbuild: add script and target to generate pacman package
> 41c196e567fb (tag: next-20240719, origin/master, origin/HEAD) Add
> linux-next specific files for 20240719
> masahiro@zoe:~/ref/linux-next((HEAD detached from origin/master))$
> make defconfig  pacman-pkg
> *** Default configuration is based on 'x86_64_defconfig'
> #
> # No change to .config
> #
> objtree="/home/masahiro/ref/linux-next" \
> BUILDDIR="" \

It is not related to this issue but I don't think this should be empty.
'realpath pacman' does not appear to work here, I was able to fix this
with the following diff:

diff --git a/scripts/Makefile.package b/scripts/Makefile.package
index 94357f47d2fa..b0fd44a40075 100644
--- a/scripts/Makefile.package
+++ b/scripts/Makefile.package
@@ -148,7 +148,7 @@ PHONY += pacman-pkg
 pacman-pkg:
 	@ln -srf $(srctree)/scripts/package/PKGBUILD $(objtree)/PKGBUILD
 	+objtree="$(realpath $(objtree))" \
-		BUILDDIR="$(realpath pacman)" \
+		BUILDDIR="$(realpath $(objtree))/pacman" \
 		CARCH="$(UTS_MACHINE)" \
 		KBUILD_MAKEFLAGS="$(MAKEFLAGS)" \
 		KBUILD_REVISION="$(shell $(srctree)/scripts/build-version)" \


> CARCH="x86_64" \
> KBUILD_MAKEFLAGS="rR --no-print-directory" \
> KBUILD_REVISION="4" \
> makepkg
> 
> ==> ERROR: An unknown error has occurred. Exiting...
> User defined signal 1
> make[3]: *** [scripts/Makefile.package:150: pacman-pkg] Error 138
> make[2]: *** [Makefile:1538: pacman-pkg] Error 2
> make[1]: *** [/home/masahiro/ref/linux-next/Makefile:347:
> __build_one_by_one] Error 2
> make: *** [Makefile:224: __sub-make] Error 2
> 
> Do you know anything?

Adding '-x' to the interpreter line in /usr/bin/makepkg shows that
pacman is implicitly required for makepkg to function, so you'll need to
install pacman-package-manager as well. However, even with it installed,
the build will fail because you will be unable to perform the dependency
checking (since pacman won't be managing the packages).

I think the traditional solution for this situation (building a
distribution's package on a distribution other than the one the package
is being built for) is using an OPTS variable to allow the user to pass
in the dependency checking skip flag (that's what I do for RPM builds on
Arch Linux), so perhaps MAKEPKGOPTS so that you can use MAKEPKGOPTS=-d?
With this diff and that variable value, the build starts within makepkg
for me.

diff --git a/scripts/Makefile.package b/scripts/Makefile.package
index b0fd44a40075..4a80584ec771 100644
--- a/scripts/Makefile.package
+++ b/scripts/Makefile.package
@@ -152,7 +152,7 @@ pacman-pkg:
 		CARCH="$(UTS_MACHINE)" \
 		KBUILD_MAKEFLAGS="$(MAKEFLAGS)" \
 		KBUILD_REVISION="$(shell $(srctree)/scripts/build-version)" \
-		makepkg
+		makepkg $(MAKEPKGOPTS)
 
 # dir-pkg tar*-pkg - tarball targets
 # ---------------------------------------------------------------------------

Cheers,
Nathan

  reply	other threads:[~2024-07-21 12:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-20  9:18 Thomas Weißschuh
2024-07-21  3:32 ` Nathan Chancellor
2024-07-21  6:58   ` Masahiro Yamada
2024-07-21 12:11     ` Nathan Chancellor [this message]
2024-07-21 13:42       ` Masahiro Yamada
2024-07-21 14:57         ` Thomas Weißschuh
2024-07-21 16:02           ` Masahiro Yamada
2024-07-21 17:21             ` Thomas Weißschuh
2024-07-21 18:42           ` Masahiro Yamada

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240721121109.GA3599565@thelio-3990X \
    --to=nathan@kernel.org \
    --cc=christian@heusel.eu \
    --cc=heftig@archlinux.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@weissschuh.net \
    --cc=masahiroy@kernel.org \
    --cc=nicolas@fjasle.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®