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