All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arseny Maslennikov <ar@cs.msu.ru>
To: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Michal Marek <michal.lkml@markovi.net>,
	Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Riku Voipio <riku.voipio@linaro.org>
Subject: Re: [PATCH] scripts/package/Makefile: put proper config in source tarball
Date: Thu, 7 Mar 2019 22:05:30 +0300	[thread overview]
Message-ID: <20190307190530.GA25561@cello> (raw)
In-Reply-To: <CAK7LNAQrN1e1GYRd760pWiAdgY9_7Jda3QD_zozTNHpHOim4Xg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2553 bytes --]

On Fri, Mar 08, 2019 at 12:32:11AM +0900, Masahiro Yamada wrote:
> On Fri, Feb 22, 2019 at 7:19 AM Arseny Maslennikov <ar@cs.msu.ru> wrote:
> >
> > It is widely known that one can build a kernel without a .config in the
> > source tree
> 
> "without a .config in the source file"  means
> KCONFIG_CONFIG will probably contain '..' or absolute path.
> 
> 
> 
> ex1)  KCONFIG_CONFIG=../my_dir/.config
> 
> ex2)  KCONFIG_CONFIG=/absolute/pass/to/my/.config
> 

Hmm, I did not consider that; my bad, sorry.

> 
> 
> 
> 
> > by setting KCONFIG_CONFIG equal to the actual configuration
> > file path.
> >
> > When making a *-pkg target, make(1) prepares a source tarball and tries
> > to pack `.config' in there regardless of the value of KCONFIG_CONFIG,
> > failing spectacularly if .config is absent and packing the wrong config
> > if it exists.
> > Let's fix that.
> 
> 
> Did you notice the log 'Removing leading ...' from tar
> for case ex1), ex2) ?
> 
> 
> masahiro@grover:~/ref/linux$ make -j8  KCONFIG_CONFIG=../.config  deb-pkg
> make clean
> /bin/bash ./scripts/package/mkdebian
>   TAR     linux-5.0.0+.tar.gz
> tar: Removing leading `../' from member names

Yes, I know tar does that. I mostly use KCONFIG_CONFIG with a bunch of
config files in the source tree, so did not experience this while making
sure the change makes sense.

>    ...
> 
> 
> Even if I apply 3/3, it will produce a broken source package
> since the tar will rip off the leading directory path,
> then it mismatches to KCONFIG_CONFIG recorded in debian/rules.
> 
> A simple case like KCONFIG_CONFIG=my.config will work,
> but I am not convinced with 3/3.
> 

So instead of this one and 3/3 we could ensure the source tarball
contains a .config equal to the contents of KCONFIG_CONFIG provided to
make(1), so the source package is fixed and its users are not confused.

If the following is ok, I'll send a v2.
A quick look at the generated orig tarball tells me it ought to work
well.

Something like this:

diff --git a/scripts/package/Makefile b/scripts/package/Makefile
index 100a0d28ad25..8530fe267a76 100644
--- a/scripts/package/Makefile
+++ b/scripts/package/Makefile
@@ -44,6 +44,7 @@ if test "$(objtree)" != "$(srctree)"; then \
 fi ; \
 $(srctree)/scripts/setlocalversion --save-scmversion; \
 tar -cz $(RCS_TAR_IGNORE) -f $(2).tar.gz \
+	--absolute-names --transform 's:^$(KCONFIG_CONFIG):.config:S' \
 	--transform 's:^:$(2)/:S' $(TAR_CONTENT) $(3); \
 rm -f $(objtree)/.scmversion
 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2019-03-07 19:05 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-21 21:58 [PATCH] scripts/package/Makefile: put proper config in source tarball Arseny Maslennikov
2019-02-21 21:58 ` [PATCH] scripts/kconfig/Makefile: use KCONFIG_CONFIG if set Arseny Maslennikov
2019-03-01 12:33   ` Petr Vorel
2019-03-09 13:12   ` Arseny Maslennikov
2019-02-21 21:58 ` [PATCH] scripts/package/mkdebian: expose KCONFIG_CONFIG to debian/rules Arseny Maslennikov
2019-03-01 13:32   ` Petr Vorel
2019-03-07 15:29   ` Masahiro Yamada
2019-03-01 13:34 ` [PATCH] scripts/package/Makefile: put proper config in source tarball Petr Vorel
2019-03-07 15:32 ` Masahiro Yamada
2019-03-07 19:05   ` Arseny Maslennikov [this message]
2019-03-07 19:08     ` Arseny Maslennikov

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=20190307190530.GA25561@cello \
    --to=ar@cs.msu.ru \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal.lkml@markovi.net \
    --cc=riku.voipio@linaro.org \
    --cc=yamada.masahiro@socionext.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.