Re: libxl dirty in tree after libxl build

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

Andrew Cooper writes ("libxl dirty in tree after libxl build"):
> A build of libxl has just dirtied the tree with:
> 
> index 05f7ac74a0..94a4438666 100644
> --- a/tools/libxl/libxlu_disk_l.c
> +++ b/tools/libxl/libxlu_disk_l.c
> @@ -10,221 +10,11 @@
>  #define FLEX_SCANNER
>  #define YY_FLEX_MAJOR_VERSION 2
>  #define YY_FLEX_MINOR_VERSION 6
> -#define YY_FLEX_SUBMINOR_VERSION 4
> +#define YY_FLEX_SUBMINOR_VERSION 1
>  #if YY_FLEX_SUBMINOR_VERSION > 0
>  #define FLEX_BETA
>  #endif
> 
> and a whole slew of other changes in the generated code.  It looks like
> the version of Flex has just been updated in Jessie.
> 
> Given the flex and bison are strictly required for the libxl build, why
> is this temporary file checked in?

The point of the exercise is to *not* require them.  The reason is
that some of our developers have very old development systems which do
not support essential flex/bison features.

How about we update them to the version from buster ?

Ian.