Re: [Xen-devel] Python version requirements vs qemu-upstream

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2014-01-15 at 10:21 +0000, Jan Beulich wrote:
> >>> On 15.01.14 at 11:03, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> > On Wed, 2014-01-15 at 09:27 +0000, Jan Beulich wrote:
> >> According to our own documentation, even Python 2.3 is supported
> >> for building,
> > 
> > It might be time to consider reving that.
> 
> Post 4.4 perhaps, but I don't think now is the right time to consider
> anything like that. IMO we ought to fix the build instead.

I think revving the minimum requirement to Python 2.4 would be a
perfectly acceptable thing to do at this stage in the release, it's
nothing more than a change to the README.

From the rest of your mail I agree that going further than that and
requiring 2.5+ would be wrong for 4.4.

> > Current state of some distros:
> > 
> > Debian Squeeze (oldstable): 2.6
> > Debian Wheezy (stable): 2.7
> > RHEL 5.9: 2.4
> > RHEL 4.8: 2.3
> > SLES 11SP3: 2.6
> > SLES 10SP4: 2.4
> > 
> > So by bumping to a minimum version of 2.4 we would be dropping support
> > for RHEL4 dom0 userspace -- Personally I think that would be acceptable,
> > it's now RHEL's old-old-stable (unless RHEL7 happened while I wasn't
> > paying attention, which is possible).
> > 
> > Bumping further than 2.4 would mean dropping RHEL5 and SLES10, neither
> > of which seem desirable to drop unnecessarily. (If there were known
> > issues with 2.4 then I would be inclined to re-evaluate that though)
> 
> As said - I encountered the issue here with 2.4 (on SLE10).

Sorry, I misunderstood and thought this was an issue with 2.3
somewhere. 

Given that it is 2.4 and Qemu's configure script explicitly says that
2.4 is what they want I think it would be worth sending the fix to qemu
upstream -- at worst they say no and bump their requirement (at which
point we'd have to have a think about what to do).

> And yes, bumping the requirement beyond 2.4 would require
> me to find solutions for how to build on SLE10 (which continues
> to be the lowest common denominator here to allow building
> and testing of all code streams I currently need to support, i.e.
> I'm keeping one system around for 32- and 64-bit each, and it
> so happens that one of those is where I do most of my work on).

This is due to your workflow, not a SLE10 requirement to support latest
Xen or anything like that, right?

(I'm not suggesting your workflow isn't important, I think if a distro
is still in use by a developer then that is good reason to keep
supporting it)

> 
> >>  yet the qemu-upstream version update results in that
> >> part of the build no longer working with Python 2.4 due to a number
> >> of conditional assignments like this
> >> 
> >>     full_name = name if not fn_prefix else "%s_%s" % (name, fn_prefix)
> >> 
> >> in scripts/qapi-visit.py.
> > 
> > This is consistent with their configure script which checks for:
> >         # Note that if the Python conditional here evaluates True we will 
> > exit
> >         # with status 1 which is a shell 'false' value.
> >         if ! $python -c 'import sys; sys.exit(sys.version_info < (2,4) or 
> > sys.version_info >= (3,))'; then
> >           error_exit "Cannot use '$python', Python 2.4 or later is 
> > required." \
> >               "Note that Python 3 or later is not yet supported." \
> >               "Use --python=/path/to/python to specify a supported Python."
> >         fi
> > 
> > Did you hit that too?
> 
> No, I didn't (or didn't notice, which would mean the failure here
> doesn't get propagated correctly) - it was the actual build that
> was failing.

OK -- now I'm confused because you seem to say you expect to have hit
this while above you say you are using Python 2.4.

> 
> >> Converting these instances to proper conditionals fixes the issue
> >> for me.
> >> 
> >> I further found that with some gcc versions trace/control-internal.h
> >> causes a huge amount of warnings to be generated. While this isn't
> >> keeping the build from succeeding, it's still rather annoying.
> > 
> > Ancient versions of gcc I presume?
> 
> Yes, 4.1.x.

Also SLE10 era I see, also RHEL5 -- so I think this one is still
important.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel