On Thu, 2013-03-28 at 23:54 +0100, Hauke Mehrtens wrote: > > Ah, what's that for? Refreshing patches? I've never seen dependencies in > > the compat patches so mostly I refresh manually, but yeah, the refresh > > part is something I'd have to think about. Though, to be honest, when > > you can just blow away your output directory and try again I'm not too > > worried about this. Trying to apply the patches could just leave it in > > the state you're in, and then you modify them until it works? > > Refreshing patches should not be a problem. Normally I use > "./scripts/admin-refresh.sh -n -p -c -u refresh" to refresh the patches > and this should work with some minor changes with the proposal you made. Ok. I have no idea what that does, since most of the time my "refreshing" isn't really refreshing but making them apply again, and I do that manually. > > Basically I'm saying the .config file only exists on the target build > > system, while the selective copying/pruning needs to be done on the > > tarball creation system. > > How do you want to make the tar generation being configurable? The build > time Kconfig options should be generated from the Kconfig files provided > by the kernel and not by some own files. Right, the build time Kconfig should just be copied as other source files. > I think some manual edited config file with the directories or files to > be included sounds good. This function would not be used by the normal > user so that should be good enough. Indeed, that's what I was thinking. Sorry for not making that clear. johannes -- To unsubscribe from this list: send the line "unsubscribe backports" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
