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:


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. :-/


ptxdist mailing list

Reply via email to