mailarchive of the ptxdist mailing list
 help / color / mirror / Atom feed
From: Alexander Dahl <ada@thorsis.com>
To: ptxdist@pengutronix.de
Subject: [ptxdist] kernel prepare stage creates extra series file
Date: Fri, 13 Oct 2017 13:53:13 +0200	[thread overview]
Message-ID: <75397751.0likpXVMv2@ada> (raw)

Hei hei,

I'm currently investigating a minor annoying issue. 

For our BSP we set PTXCONF_PLATFORM to something like 'at91foo'. Recently we 
added some kernel patches (we didn't have those before when using a pure 
vanilla kernel, this is no option anymore) and we put those to $
(PTXDIST_WORKSPACE)/patches (where our other patches are) and created a file 
'linux-4.9.47/series.at91foo' in the subdirectory matching the currently used 
kernel version. This works so far, build is successful, image is created and 
runs on target.

To those patches: we track our patches in a separate Git repository and use it 
as a Git submodule in more than one BSP, not below the 
PTXDIST_PLATFORMCONFIGDIR (where the platform specific linux patches maybe 
should go), but below PTXDIST_WORKSPACE, because it's a shared patches folder 
anyway. Maybe also not the best decision, but it's like that currently.

The linux kernel patch stack was created with 'git ptx-patches', but on a 
clean build I deactivated PTXCONF_SETUP_PATCHIN_GIT so patches are applied 
without git, this saves quite some time on extract stage.

Now after a `ptxdist clean` and a `ptxdist prepare kernel` a new 'series' file 
appears in $(PTXDIST_WORKSPACE)/patches/linux-4.9.47 and it's only named 
'series' and put besides the already present 'series.at91foo' which is tracked 
in Git. In the patches folder Git lists this as untracked file. In the parent 
folder, which is PTXDIST_WORKSPACE aka the BSP using the patches folder as a 
Git submodule and tracked in a different Git repo, on `git status` I see this:

	modified:   patches (untracked content)

And with `git describe --tags --dirty` this:

	v2017.03.0-275-gd8e18cb-dirty

We use this somewhere in our firmware. Now on a clean build, we must abort in 
between, remove this additional series file, and proceed the build to get a 
clean version string without '-dirty' added. :-(

From my intuition I would say ptxdist should not create this additional series 
file, or delete it again, if it's just temporary. I tried to find the spot in 
ptxdist sources, but up to now with no luck.

Is this a bug in ptxdist? Should we organize our BSPs and patches somehow 
different to not run into this? Are there any other possibilities or 
suggestions? This behaviour is problematic for fully automatic builds. :-/

Greets
Alex


_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

             reply	other threads:[~2017-10-13 11:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-13 11:53 Alexander Dahl [this message]
2017-10-16 12:40 ` Michael Olbrich
2017-10-16 13:26   ` Alexander Dahl
2017-10-16 13:42     ` Michael Olbrich
2017-10-16 13:52       ` Alexander Dahl

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=75397751.0likpXVMv2@ada \
    --to=ada@thorsis.com \
    --cc=ptxdist@pengutronix.de \
    /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