Supporting upcoming distribution releases

Supporting upcoming distribution releases

[Joshua Lock]

In our technical team call today we spent some time discussing how to
support distribution releases that are due to happen around the time of
Yocto 1.1.

Yocto 1.1 is scheduled for release on October 6th[1], the same month in
which both Ubuntu and Fedora have new releases planned[2,3].
OpenSUSE doesn't have a release scheduled until November 10th[4].

We should accommodate for these releases in our planning around 1.1 as
we need to ensure that Yocto 1.1 can be used on the new versions of the
chosen supported distros.

I had initially suggested we have people doing test and any relevant
development around the beta cycles of Ubuntu and Fedora:

Fedora Beta (2011-09-20)
Ubuntu (2011-09-01)
In this time frame OpenSUSE will be on Milestone 5 (2011-09-01) which
afaict (based on the 6th milestone being followed by an RC) should
roughly equate to a beta.

However this aligns with our RC period at which point we may not want to
accept large patches?

To meet our stabilise complete goal of August 29th we'd have to have
people testing with:
Fedora Alpha (2011-08-16)
Ubuntu Alpha 3 (2011-08-04)
OpenSUSE Milestone 4 (2011-08-11)

What are peoples thoughts on this? I think the onus for this testing
will fall on engineers as the project QA is already pretty stretched. I
have a tendency to update to early releases on at least one machine so
will no doubt do some testing on Fedora but it would be nice to have a
genuine strategy for this rather than relying on ad-hoc developer
upgrades.

Final note: I'm left wondering if this emails contents also make sense
as a wiki page?

Cheers,
Joshua

1. https://wiki.pokylinux.org/wiki/Yocto_1.1_Schedule
2. https://wiki.ubuntu.com/OneiricReleaseSchedule
3. http://fedoraproject.org/wiki/Releases/16/Schedule
4. http://en.opensuse.org/Roadmap
-- 
Joshua Lock
        Yocto Project "Johannes factotum"
        Intel Open Source Technology Centre

Re: Supporting upcoming distribution releases

[Darren Hart]

On 07/12/2011 11:51 AM, Joshua Lock wrote:
> In our technical team call today we spent some time discussing how to
> support distribution releases that are due to happen around the time of
> Yocto 1.1.
> 
> Yocto 1.1 is scheduled for release on October 6th[1], the same month in
> which both Ubuntu and Fedora have new releases planned[2,3].
> OpenSUSE doesn't have a release scheduled until November 10th[4].
> 
> We should accommodate for these releases in our planning around 1.1 as
> we need to ensure that Yocto 1.1 can be used on the new versions of the
> chosen supported distros.
> 
> I had initially suggested we have people doing test and any relevant
> development around the beta cycles of Ubuntu and Fedora:
> 
> Fedora Beta (2011-09-20)
> Ubuntu (2011-09-01)
> In this time frame OpenSUSE will be on Milestone 5 (2011-09-01) which
> afaict (based on the 6th milestone being followed by an RC) should
> roughly equate to a beta.
> 
> However this aligns with our RC period at which point we may not want to
> accept large patches?
> 
> To meet our stabilise complete goal of August 29th we'd have to have
> people testing with:
> Fedora Alpha (2011-08-16)
> Ubuntu Alpha 3 (2011-08-04)
> OpenSUSE Milestone 4 (2011-08-11)
> 
> What are peoples thoughts on this?

At the very least a sanity test to know which sorts of issues we'll hit
with these would be valuable. However, I believe our policy is N-1, and
not N+1,N,N-1, so supporting not-yet released versions isn't something I
think we should spend too much time on. Minor fixes to support these
post release seem like good candidates for a point release.

> I think the onus for this testing
> will fall on engineers as the project QA is already pretty stretched. I
> have a tendency to update to early releases on at least one machine so
> will no doubt do some testing on Fedora but it would be nice to have a
> genuine strategy for this rather than relying on ad-hoc developer
> upgrades.


I personally do not upgrade my primary development machine to
pre-release distributions because I don't want those issues to derail me
from working on features. However, I could certainly kick off VMs
running whatever and set them building on one of our larger servers.

> 
> Final note: I'm left wondering if this emails contents also make sense
> as a wiki page?

Some sort of distro links for schedule page would be great. If people
want to share that they are testing the pre-release distros, that would
be useful, but we need to find a way to keep it concise and not into a
"getting it to work on XYZ" forum - although that would be useful a
separate page per distro.

> 
> Cheers,
> Joshua
> 
> 1. https://wiki.pokylinux.org/wiki/Yocto_1.1_Schedule
> 2. https://wiki.ubuntu.com/OneiricReleaseSchedule
> 3. http://fedoraproject.org/wiki/Releases/16/Schedule
> 4. http://en.opensuse.org/Roadmap

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: Supporting upcoming distribution releases

[Joshua Lock]

On Tue, 2011-07-12 at 12:01 -0700, Darren Hart wrote:
> 
> On 07/12/2011 11:51 AM, Joshua Lock wrote:
> > In our technical team call today we spent some time discussing how to
> > support distribution releases that are due to happen around the time of
> > Yocto 1.1.
> > 
> > Yocto 1.1 is scheduled for release on October 6th[1], the same month in
> > which both Ubuntu and Fedora have new releases planned[2,3].
> > OpenSUSE doesn't have a release scheduled until November 10th[4].
> > 
> > We should accommodate for these releases in our planning around 1.1 as
> > we need to ensure that Yocto 1.1 can be used on the new versions of the
> > chosen supported distros.
> > 
> > I had initially suggested we have people doing test and any relevant
> > development around the beta cycles of Ubuntu and Fedora:
> > 
> > Fedora Beta (2011-09-20)
> > Ubuntu (2011-09-01)
> > In this time frame OpenSUSE will be on Milestone 5 (2011-09-01) which
> > afaict (based on the 6th milestone being followed by an RC) should
> > roughly equate to a beta.
> > 
> > However this aligns with our RC period at which point we may not want to
> > accept large patches?
> > 
> > To meet our stabilise complete goal of August 29th we'd have to have
> > people testing with:
> > Fedora Alpha (2011-08-16)
> > Ubuntu Alpha 3 (2011-08-04)
> > OpenSUSE Milestone 4 (2011-08-11)
> > 
> > What are peoples thoughts on this?
> 
> At the very least a sanity test to know which sorts of issues we'll hit
> with these would be valuable. However, I believe our policy is N-1, and
> not N+1,N,N-1, so supporting not-yet released versions isn't something I
> think we should spend too much time on. Minor fixes to support these
> post release seem like good candidates for a point release.

I understand what you're saying but I think the stance bears further
consideration because our release is so close to that of the
distributions and because so many of our target users will upgrade on
release day (or sooner) I think it's in the interest of the project to
be aware of the issues before release and ideally to have fixed as many
of any issues as possible.

I don't think it likely we will spin a point release in time to have
something that works on the distro launch day if we take the approach
you're advocating.

If people think this isn't a big deal I can live with that, but
experience suggests we will field support enquiries about these things
and therefore to my mind it seems prudent to accommodate for that.

> > I think the onus for this testing
> > will fall on engineers as the project QA is already pretty stretched. I
> > have a tendency to update to early releases on at least one machine so
> > will no doubt do some testing on Fedora but it would be nice to have a
> > genuine strategy for this rather than relying on ad-hoc developer
> > upgrades.
> 
> 
> I personally do not upgrade my primary development machine to
> pre-release distributions because I don't want those issues to derail me
> from working on features. However, I could certainly kick off VMs
> running whatever and set them building on one of our larger servers.

Absolutely. I'm not meaning to suggest all our developers should run
unstable OS's.

Aside; the schedule has feature development long complete by this
point ;-)

> 
> > 
> > Final note: I'm left wondering if this emails contents also make sense
> > as a wiki page?
> 
> Some sort of distro links for schedule page would be great. If people
> want to share that they are testing the pre-release distros, that would
> be useful, but we need to find a way to keep it concise and not into a
> "getting it to work on XYZ" forum - although that would be useful a
> separate page per distro.

Or perhaps we should just integrate this information into our schedule?

Cheers,
Joshua
-- 
Joshua Lock
        Yocto Project "Johannes factotum"
        Intel Open Source Technology Centre

Re: Supporting upcoming distribution releases

[Darren Hart]

On 07/12/2011 12:26 PM, Joshua Lock wrote:
> On Tue, 2011-07-12 at 12:01 -0700, Darren Hart wrote:
>>

>>> Final note: I'm left wondering if this emails contents also make sense
>>> as a wiki page?
>>
>> Some sort of distro links for schedule page would be great. If people
>> want to share that they are testing the pre-release distros, that would
>> be useful, but we need to find a way to keep it concise and not into a
>> "getting it to work on XYZ" forum - although that would be useful a
>> separate page per distro.
> 
> Or perhaps we should just integrate this information into our schedule?

That is a great idea!

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: Supporting upcoming distribution releases

[Richard Purdie]

On Tue, 2011-07-12 at 12:01 -0700, Darren Hart wrote:
> 
> On 07/12/2011 11:51 AM, Joshua Lock wrote:
> > In our technical team call today we spent some time discussing how to
> > support distribution releases that are due to happen around the time of
> > Yocto 1.1.
> > 
> > Yocto 1.1 is scheduled for release on October 6th[1], the same month in
> > which both Ubuntu and Fedora have new releases planned[2,3].
> > OpenSUSE doesn't have a release scheduled until November 10th[4].
> > 
> > We should accommodate for these releases in our planning around 1.1 as
> > we need to ensure that Yocto 1.1 can be used on the new versions of the
> > chosen supported distros.
> > 
> > I had initially suggested we have people doing test and any relevant
> > development around the beta cycles of Ubuntu and Fedora:
> > 
> > Fedora Beta (2011-09-20)
> > Ubuntu (2011-09-01)
> > In this time frame OpenSUSE will be on Milestone 5 (2011-09-01) which
> > afaict (based on the 6th milestone being followed by an RC) should
> > roughly equate to a beta.
> > 
> > However this aligns with our RC period at which point we may not want to
> > accept large patches?
> > 
> > To meet our stabilise complete goal of August 29th we'd have to have
> > people testing with:
> > Fedora Alpha (2011-08-16)
> > Ubuntu Alpha 3 (2011-08-04)
> > OpenSUSE Milestone 4 (2011-08-11)
> > 
> > What are peoples thoughts on this?
> 
> At the very least a sanity test to know which sorts of issues we'll hit
> with these would be valuable. However, I believe our policy is N-1, and
> not N+1,N,N-1, so supporting not-yet released versions isn't something I
> think we should spend too much time on. Minor fixes to support these
> post release seem like good candidates for a point release.

Much as I'd like to agree with you, traditionally this does tend to bite
us hard. The fixes some of the releases have needed are sometimes not so
minor too :(.

The reason is that we have a community with a significant portion of
people who do stay close to the edge as far as distros go. They'll take
latest releases and expect Yocto to work on them even if the releases
come out at the same time. Its not often realised how far in advance
trees get frozen for stabilisation.

So summary is I'm in favour of trying to identify problems early and
then doing what we can to address them...

As such, this time around I'll update my build machine to latest Ubuntu
at the beginning of August....

Cheers,

Richard

Re: Supporting upcoming distribution releases

[NiQingliang]

I think Archlinux is the preferred choice.-_-
Just joke.

I doubt why the bitbake need python2.x but just use /bin/env python. I
think If it need a specific version python, it should write it in the
shebang. e.g. /bin/env python2.6

On Wed, 2011-07-13 at 05:08 +0800, Richard Purdie wrote:
> On Tue, 2011-07-12 at 12:01 -0700, Darren Hart wrote:
> >
> > On 07/12/2011 11:51 AM, Joshua Lock wrote:
> > > In our technical team call today we spent some time discussing how to
> > > support distribution releases that are due to happen around the time of
> > > Yocto 1.1.
> > >
> > > Yocto 1.1 is scheduled for release on October 6th[1], the same month in
> > > which both Ubuntu and Fedora have new releases planned[2,3].
> > > OpenSUSE doesn't have a release scheduled until November 10th[4].
> > >
> > > We should accommodate for these releases in our planning around 1.1 as
> > > we need to ensure that Yocto 1.1 can be used on the new versions of the
> > > chosen supported distros.
> > >
> > > I had initially suggested we have people doing test and any relevant
> > > development around the beta cycles of Ubuntu and Fedora:
> > >
> > > Fedora Beta (2011-09-20)
> > > Ubuntu (2011-09-01)
> > > In this time frame OpenSUSE will be on Milestone 5 (2011-09-01) which
> > > afaict (based on the 6th milestone being followed by an RC) should
> > > roughly equate to a beta.
> > >
> > > However this aligns with our RC period at which point we may not want to
> > > accept large patches?
> > >
> > > To meet our stabilise complete goal of August 29th we'd have to have
> > > people testing with:
> > > Fedora Alpha (2011-08-16)
> > > Ubuntu Alpha 3 (2011-08-04)
> > > OpenSUSE Milestone 4 (2011-08-11)
> > >
> > > What are peoples thoughts on this?
> >
> > At the very least a sanity test to know which sorts of issues we'll hit
> > with these would be valuable. However, I believe our policy is N-1, and
> > not N+1,N,N-1, so supporting not-yet released versions isn't something I
> > think we should spend too much time on. Minor fixes to support these
> > post release seem like good candidates for a point release.
> 
> Much as I'd like to agree with you, traditionally this does tend to bite
> us hard. The fixes some of the releases have needed are sometimes not so
> minor too :(.
> 
> The reason is that we have a community with a significant portion of
> people who do stay close to the edge as far as distros go. They'll take
> latest releases and expect Yocto to work on them even if the releases
> come out at the same time. Its not often realised how far in advance
> trees get frozen for stabilisation.
> 
> So summary is I'm in favour of trying to identify problems early and
> then doing what we can to address them...
> 
> As such, this time around I'll update my build machine to latest Ubuntu
> at the beginning of August....
> 
> Cheers,
> 
> Richard
> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

-- 
倪庆亮
TEL:    13588371863
E-MAIL: niqingliang@insigma.com.cn
BLOG:   http://niqingliang2003.wordpress.com

Re: Supporting upcoming distribution releases

[Joshua Lock]

On Wed, 2011-07-13 at 09:15 +0800, NiQingliang wrote:
> I think Archlinux is the preferred choice.-_-
> Just joke.
> 
> I doubt why the bitbake need python2.x but just use /bin/env python. I
> think If it need a specific version python, it should write it in the
> shebang. e.g. /bin/env python2.6

I looked at this but not enough of the distributions we care to support
have a python2.6 binary:

joshual@scimitar:~
$ /usr/bin/env python2
Python 2.7.1 (r271:86832, Apr 12 2011, 16:16:18) 
[GCC 4.6.0 20110331 (Red Hat 4.6.0-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 
joshual@scimitar:~
$ /usr/bin/env python2.6
/usr/bin/env: python2.6: No such file or directory

I'd love to support Arch more thoroughly but they aren't making it easy
for us ;-)

Cheers,
Joshua
-- 
Joshua Lock
        Yocto Project "Johannes factotum"
        Intel Open Source Technology Centre

Re: Supporting upcoming distribution releases

[NiQingliang]

/usr/bin/env python2 
/usr/bin/env python2.7
both of them are ok for archlinux, but I don't know which is ok for
other distributions, maybe both are not.

maybe we can make a shell script to detect the python version, and make
a symbollink to the right one in some directory, and add the directory
into env var "PATH".


On Wed, 2011-07-13 at 10:08 +0800, Joshua Lock wrote:
> On Wed, 2011-07-13 at 09:15 +0800, NiQingliang wrote:
> > I think Archlinux is the preferred choice.-_-
> > Just joke.
> >
> > I doubt why the bitbake need python2.x but just use /bin/env python. I
> > think If it need a specific version python, it should write it in the
> > shebang. e.g. /bin/env python2.6
> 
> I looked at this but not enough of the distributions we care to support
> have a python2.6 binary:
> 
> joshual@scimitar:~
> $ /usr/bin/env python2
> Python 2.7.1 (r271:86832, Apr 12 2011, 16:16:18)
> [GCC 4.6.0 20110331 (Red Hat 4.6.0-2)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>>
> joshual@scimitar:~
> $ /usr/bin/env python2.6
> /usr/bin/env: python2.6: No such file or directory
> 
> I'd love to support Arch more thoroughly but they aren't making it easy
> for us ;-)
> 
> Cheers,
> Joshua
> --
> Joshua Lock
>         Yocto Project "Johannes factotum"
>         Intel Open Source Technology Centre
> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

-- 
倪庆亮
TEL:    13588371863
E-MAIL: niqingliang@insigma.com.cn
BLOG:   http://niqingliang2003.wordpress.com

Re: Supporting upcoming distribution releases

[Joshua Lock]

On Wed, 2011-07-13 at 10:19 +0800, NiQingliang wrote:
> /usr/bin/env python2 
> /usr/bin/env python2.7

These are both valid on Fedora 15, iirc before distributions started
shipping Python 3 they were less common though...

> both of them are ok for archlinux, but I don't know which is ok for
> other distributions, maybe both are not.
> 
> maybe we can make a shell script to detect the python version, and make
> a symbollink to the right one in some directory, and add the directory
> into env var "PATH".

Patches welcome :-)

I looked at it briefly and the work would require more time than I have
spare right now just to ensure it worked on all required distributions.

If you'd like to work on a patch I'd be happy to help test and review.

Cheers,
Joshua
-- 
Joshua Lock
        Yocto Project "Johannes factotum"
        Intel Open Source Technology Centre

Re: Supporting upcoming distribution releases

[NiQingliang]

OK, I will do it.:)

On Wed, 2011-07-13 at 10:31 +0800, Joshua Lock wrote:
> On Wed, 2011-07-13 at 10:19 +0800, NiQingliang wrote:
> > /usr/bin/env python2
> > /usr/bin/env python2.7
> 
> These are both valid on Fedora 15, iirc before distributions started
> shipping Python 3 they were less common though...
> 
> > both of them are ok for archlinux, but I don't know which is ok for
> > other distributions, maybe both are not.
> >
> > maybe we can make a shell script to detect the python version, and make
> > a symbollink to the right one in some directory, and add the directory
> > into env var "PATH".
> 
> Patches welcome :-)
> 
> I looked at it briefly and the work would require more time than I have
> spare right now just to ensure it worked on all required distributions.
> 
> If you'd like to work on a patch I'd be happy to help test and review.
> 
> Cheers,
> Joshua
> --
> Joshua Lock
>         Yocto Project "Johannes factotum"
>         Intel Open Source Technology Centre
> 

-- 
倪庆亮
TEL:    13588371863
E-MAIL: niqingliang@insigma.com.cn
BLOG:   http://niqingliang2003.wordpress.com

Re: Supporting upcoming distribution releases

[NiQingliang]

first sorry about that, indeed I don't know how to commit a patch, so
just paste the diff result here.

diff --git a/oe-init-build-env b/oe-init-build-env
index 77332a7..0da8bc0 100755
--- a/oe-init-build-env
+++ b/oe-init-build-env
@@ -39,6 +39,20 @@ else
    $OEROOT/scripts/oe-setup-builddir
    unset OEROOT
    unset BBPATH
+
+   # find the python version 2.x
+   # the 'python -V' need redirect to stdout
+   # precondition:
+   #    $BUILDDIR is not NULL, but I doubt when it will be NULL.
+   #    user have not made the file $BUILDDIR/python by himself.
+   for PY_BIN in `find /{usr/,}bin -regex '.*/python\(\|2\|2\.[0-9]*
\)'`; do
+      if [ -n "`$PY_BIN -V 2>&1|grep '^Python 2\.'`" ]; then
+         ln -sf $PY_BIN $BUILDDIR/python
+         export PATH="$BUILDDIR:$PATH"
+         break
+      fi
+   done
+
    [ -n "$BUILDDIR" ] && cd $BUILDDIR
 fi


On Wed, 2011-07-13 at 10:31 +0800, Joshua Lock wrote:
> On Wed, 2011-07-13 at 10:19 +0800, NiQingliang wrote:
> > /usr/bin/env python2
> > /usr/bin/env python2.7
> 
> These are both valid on Fedora 15, iirc before distributions started
> shipping Python 3 they were less common though...
> 
> > both of them are ok for archlinux, but I don't know which is ok for
> > other distributions, maybe both are not.
> >
> > maybe we can make a shell script to detect the python version, and make
> > a symbollink to the right one in some directory, and add the directory
> > into env var "PATH".
> 
> Patches welcome :-)
> 
> I looked at it briefly and the work would require more time than I have
> spare right now just to ensure it worked on all required distributions.
> 
> If you'd like to work on a patch I'd be happy to help test and review.
> 
> Cheers,
> Joshua
> --
> Joshua Lock
>         Yocto Project "Johannes factotum"
>         Intel Open Source Technology Centre
> 

-- 
倪庆亮
TEL:    13588371863
E-MAIL: niqingliang@insigma.com.cn
BLOG:   http://niqingliang2003.wordpress.com

Re: Supporting upcoming distribution releases

[Darren Hart]

On 07/13/2011 01:04 AM, NiQingliang wrote:
> first sorry about that, indeed I don't know how to commit a patch, so
> just paste the diff result here.
> 
> diff --git a/oe-init-build-env b/oe-init-build-env
> index 77332a7..0da8bc0 100755
> --- a/oe-init-build-env
> +++ b/oe-init-build-env
> @@ -39,6 +39,20 @@ else
>     $OEROOT/scripts/oe-setup-builddir
>     unset OEROOT
>     unset BBPATH
> +

Before searching manually, we should attempt to use whatever is set in
the environment.

--
Darren

> +   # find the python version 2.x
> +   # the 'python -V' need redirect to stdout
> +   # precondition:
> +   #    $BUILDDIR is not NULL, but I doubt when it will be NULL.
> +   #    user have not made the file $BUILDDIR/python by himself.
> +   for PY_BIN in `find /{usr/,}bin -regex '.*/python\(\|2\|2\.[0-9]*
> \)'`; do
> +      if [ -n "`$PY_BIN -V 2>&1|grep '^Python 2\.'`" ]; then
> +         ln -sf $PY_BIN $BUILDDIR/python
> +         export PATH="$BUILDDIR:$PATH"
> +         break
> +      fi
> +   done
> +
>     [ -n "$BUILDDIR" ] && cd $BUILDDIR
>  fi
> 
> 
> On Wed, 2011-07-13 at 10:31 +0800, Joshua Lock wrote:
>> On Wed, 2011-07-13 at 10:19 +0800, NiQingliang wrote:
>>> /usr/bin/env python2
>>> /usr/bin/env python2.7
>>
>> These are both valid on Fedora 15, iirc before distributions started
>> shipping Python 3 they were less common though...
>>
>>> both of them are ok for archlinux, but I don't know which is ok for
>>> other distributions, maybe both are not.
>>>
>>> maybe we can make a shell script to detect the python version, and make
>>> a symbollink to the right one in some directory, and add the directory
>>> into env var "PATH".
>>
>> Patches welcome :-)
>>
>> I looked at it briefly and the work would require more time than I have
>> spare right now just to ensure it worked on all required distributions.
>>
>> If you'd like to work on a patch I'd be happy to help test and review.
>>
>> Cheers,
>> Joshua
>> --
>> Joshua Lock
>>         Yocto Project "Johannes factotum"
>>         Intel Open Source Technology Centre
>>
> 

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Re: Supporting upcoming distribution releases

[NiQingliang]

You are right, I will fix it.

On Thu, 2011-07-14 at 01:01 +0800, Darren Hart wrote:
> 
> On 07/13/2011 01:04 AM, NiQingliang wrote:
> > first sorry about that, indeed I don't know how to commit a patch, so
> > just paste the diff result here.
> >
> > diff --git a/oe-init-build-env b/oe-init-build-env
> > index 77332a7..0da8bc0 100755
> > --- a/oe-init-build-env
> > +++ b/oe-init-build-env
> > @@ -39,6 +39,20 @@ else
> >     $OEROOT/scripts/oe-setup-builddir
> >     unset OEROOT
> >     unset BBPATH
> > +
> 
> Before searching manually, we should attempt to use whatever is set in
> the environment.
> 
> --
> Darren
> 
> > +   # find the python version 2.x
> > +   # the 'python -V' need redirect to stdout
> > +   # precondition:
> > +   #    $BUILDDIR is not NULL, but I doubt when it will be NULL.
> > +   #    user have not made the file $BUILDDIR/python by himself.
> > +   for PY_BIN in `find /{usr/,}bin -regex '.*/python\(\|2\|2\.[0-9]*
> > \)'`; do
> > +      if [ -n "`$PY_BIN -V 2>&1|grep '^Python 2\.'`" ]; then
> > +         ln -sf $PY_BIN $BUILDDIR/python
> > +         export PATH="$BUILDDIR:$PATH"
> > +         break
> > +      fi
> > +   done
> > +
> >     [ -n "$BUILDDIR" ] && cd $BUILDDIR
> >  fi
> >
> >
> > On Wed, 2011-07-13 at 10:31 +0800, Joshua Lock wrote:
> >> On Wed, 2011-07-13 at 10:19 +0800, NiQingliang wrote:
> >>> /usr/bin/env python2
> >>> /usr/bin/env python2.7
> >>
> >> These are both valid on Fedora 15, iirc before distributions started
> >> shipping Python 3 they were less common though...
> >>
> >>> both of them are ok for archlinux, but I don't know which is ok for
> >>> other distributions, maybe both are not.
> >>>
> >>> maybe we can make a shell script to detect the python version, and make
> >>> a symbollink to the right one in some directory, and add the directory
> >>> into env var "PATH".
> >>
> >> Patches welcome :-)
> >>
> >> I looked at it briefly and the work would require more time than I have
> >> spare right now just to ensure it worked on all required distributions.
> >>
> >> If you'd like to work on a patch I'd be happy to help test and review.
> >>
> >> Cheers,
> >> Joshua
> >> --
> >> Joshua Lock
> >>         Yocto Project "Johannes factotum"
> >>         Intel Open Source Technology Centre
> >>
> >
> 
> --
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Linux Kernel

-- 
倪庆亮
TEL:    13588371863
E-MAIL: niqingliang@insigma.com.cn
BLOG:   http://niqingliang2003.wordpress.com

Re: Supporting upcoming distribution releases

[NiQingliang]

new version

diff --git a/oe-init-build-env b/oe-init-build-env
index 77332a7..0fe1b5e 100755
--- a/oe-init-build-env
+++ b/oe-init-build-env
@@ -39,6 +39,35 @@ else
    $OEROOT/scripts/oe-setup-builddir
    unset OEROOT
    unset BBPATH
+
+   # find the python 2.x, if the default python is not.
+   # NOTE:
+   #    the 'python -V' need redirect to stdout
+   #    once we can ensure every distribution has 'python2' (currently,
except
+   #    ubuntu), we should change bitbake's shebang to '/usr/bin/env
python2',
+   #    and remove this patch.
+   # precondition:
+   #    $BUILDDIR is not NULL, but I doubt when it will be NULL.
+   #    user have not made the file $BUILDDIR/python by himself.
+   if [ -z "`/usr/bin/env python -V 2>&1|grep '^Python 2\.'`" ]; then
+      echo "WARNING: your default python is not 2.x, so autodetect..."
+      PYTHON2_BIN=""
+      for PY_BIN in `find /{usr/,}bin -regex '.*/python\(\|2\|2\.[0-9]*
\)'`; do
+         if [ -n "`$PY_BIN -V 2>&1|grep '^Python 2\.'`" ]; then
+            PYTHON2_BIN=$PY_BIN
+            break
+         fi
+      done
+      if [ -n "$PYTHON2_BIN" ]; then
+         ln -sf $PY_BIN $BUILDDIR/python
+         export PATH="$BUILDDIR:$PATH"
+         echo "WARNING: poky will use '$PY_BIN' to execute python
code."
+      else
+         echo "ERROR: poky can't find python 2.x."
+      fi
+      unset PYTHON2_BIN
+   fi
+
    [ -n "$BUILDDIR" ] && cd $BUILDDIR
 fi



On Thu, 2011-07-14 at 01:01 +0800, Darren Hart wrote:
> 
> On 07/13/2011 01:04 AM, NiQingliang wrote:
> > first sorry about that, indeed I don't know how to commit a patch, so
> > just paste the diff result here.
> >
> > diff --git a/oe-init-build-env b/oe-init-build-env
> > index 77332a7..0da8bc0 100755
> > --- a/oe-init-build-env
> > +++ b/oe-init-build-env
> > @@ -39,6 +39,20 @@ else
> >     $OEROOT/scripts/oe-setup-builddir
> >     unset OEROOT
> >     unset BBPATH
> > +
> 
> Before searching manually, we should attempt to use whatever is set in
> the environment.
> 
> --
> Darren
> 
> > +   # find the python version 2.x
> > +   # the 'python -V' need redirect to stdout
> > +   # precondition:
> > +   #    $BUILDDIR is not NULL, but I doubt when it will be NULL.
> > +   #    user have not made the file $BUILDDIR/python by himself.
> > +   for PY_BIN in `find /{usr/,}bin -regex '.*/python\(\|2\|2\.[0-9]*
> > \)'`; do
> > +      if [ -n "`$PY_BIN -V 2>&1|grep '^Python 2\.'`" ]; then
> > +         ln -sf $PY_BIN $BUILDDIR/python
> > +         export PATH="$BUILDDIR:$PATH"
> > +         break
> > +      fi
> > +   done
> > +
> >     [ -n "$BUILDDIR" ] && cd $BUILDDIR
> >  fi
> >
> >
> > On Wed, 2011-07-13 at 10:31 +0800, Joshua Lock wrote:
> >> On Wed, 2011-07-13 at 10:19 +0800, NiQingliang wrote:
> >>> /usr/bin/env python2
> >>> /usr/bin/env python2.7
> >>
> >> These are both valid on Fedora 15, iirc before distributions started
> >> shipping Python 3 they were less common though...
> >>
> >>> both of them are ok for archlinux, but I don't know which is ok for
> >>> other distributions, maybe both are not.
> >>>
> >>> maybe we can make a shell script to detect the python version, and make
> >>> a symbollink to the right one in some directory, and add the directory
> >>> into env var "PATH".
> >>
> >> Patches welcome :-)
> >>
> >> I looked at it briefly and the work would require more time than I have
> >> spare right now just to ensure it worked on all required distributions.
> >>
> >> If you'd like to work on a patch I'd be happy to help test and review.
> >>
> >> Cheers,
> >> Joshua
> >> --
> >> Joshua Lock
> >>         Yocto Project "Johannes factotum"
> >>         Intel Open Source Technology Centre
> >>
> >
> 
> --
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Linux Kernel

-- 
倪庆亮
TEL:    13588371863
E-MAIL: niqingliang@insigma.com.cn
BLOG:   http://niqingliang2003.wordpress.com

Re: Supporting upcoming distribution releases

[Joshua Lock]

On Thu, 2011-07-14 at 09:34 +0800, NiQingliang wrote:
> new version
> 
> diff --git a/oe-init-build-env b/oe-init-build-env
> index 77332a7..0fe1b5e 100755
> --- a/oe-init-build-env
> +++ b/oe-init-build-env
> @@ -39,6 +39,35 @@ else
>     $OEROOT/scripts/oe-setup-builddir
>     unset OEROOT
>     unset BBPATH
> +
> +   # find the python 2.x, if the default python is not.
> +   # NOTE:
> +   #    the 'python -V' need redirect to stdout
> +   #    once we can ensure every distribution has 'python2' (currently,
> except
> +   #    ubuntu), we should change bitbake's shebang to '/usr/bin/env
> python2',
> +   #    and remove this patch.
> +   # precondition:
> +   #    $BUILDDIR is not NULL, but I doubt when it will be NULL.
> +   #    user have not made the file $BUILDDIR/python by himself.
> +   if [ -z "`/usr/bin/env python -V 2>&1|grep '^Python 2\.'`" ]; then
> +      echo "WARNING: your default python is not 2.x, so autodetect..."

I'm not sure we need to print this.

> +      PYTHON2_BIN=""
> +      for PY_BIN in `find /{usr/,}bin -regex '.*/python\(\|2\|2\.[0-9]*
> \)'`; do
> +         if [ -n "`$PY_BIN -V 2>&1|grep '^Python 2\.'`" ]; then
> +            PYTHON2_BIN=$PY_BIN
> +            break
> +         fi
> +      done
> +      if [ -n "$PYTHON2_BIN" ]; then
> +         ln -sf $PY_BIN $BUILDDIR/python
> +         export PATH="$BUILDDIR:$PATH"
> +         echo "WARNING: poky will use '$PY_BIN' to execute python
> code."

I can live without this message but if we do leave it in we should
probably call it a NOTE rather than WARNING.

> +      else
> +         echo "ERROR: poky can't find python 2.x."

Perhaps make this a little more informative?

ERROR: unable to find Python 2.x, BitBake requires Python 2.6 or 2.7.

> +      fi
> +      unset PYTHON2_BIN
> +   fi
> +
>     [ -n "$BUILDDIR" ] && cd $BUILDDIR
>  fi

I can verify that this works as expected (i.e. does nothing) on my
Fedora 15 machine with Python 2.7.1.

Could you submit the patch to the openembedded-core mailing list so that
it can be considered for inclusion in the Yocto project's shared
upstream?

Thanks,
Joshua
-- 
Joshua Lock
        Yocto Project "Johannes factotum"
        Intel Open Source Technology Centre

Re: Supporting upcoming distribution releases

[NiQingliang]

update accroding your suggestion.
This patch is for bitbake indeed, but bitbake is not part of
openembedded. Is it RIGHT?


diff --git a/oe-init-build-env b/oe-init-build-env
index 77332a7..acf4e96 100755
--- a/oe-init-build-env
+++ b/oe-init-build-env
@@ -39,6 +39,34 @@ else
    $OEROOT/scripts/oe-setup-builddir
    unset OEROOT
    unset BBPATH
+
+   # find the python 2.x, if the default python is not.
+   # NOTE:
+   #    the 'python -V' need redirect to stdout
+   #    once we can ensure every distribution has 'python2' (currently,
except
+   #    ubuntu), we should change bitbake's shebang to '/usr/bin/env
python2',
+   #    and remove this patch.
+   # precondition:
+   #    $BUILDDIR is not NULL, but I doubt when it will be NULL.
+   #    user have not made the file $BUILDDIR/python by himself.
+   if [ -z "`/usr/bin/env python -V 2>&1|grep '^Python 2\.'`" ]; then
+      PYTHON2_BIN=""
+      for PY_BIN in `find /{usr/,}bin -regex '.*/python\(\|2\|2\.[0-9]*
\)'`; do
+         if [ -n "`$PY_BIN -V 2>&1|grep '^Python 2\.'`" ]; then
+            PYTHON2_BIN=$PY_BIN
+            break
+         fi
+      done
+      if [ -n "$PYTHON2_BIN" ]; then
+         ln -sf $PY_BIN $BUILDDIR/python
+         export PATH="$BUILDDIR:$PATH"
+         echo "NOTE: poky will use '$PY_BIN' to execute python code."
+      else
+         echo "ERROR: unable to find Python 2.x, BitBake requires
Python 2.6 or
+      fi
+      unset PYTHON2_BIN
+   fi
+
    [ -n "$BUILDDIR" ] && cd $BUILDDIR
 fi


On Wed, 2011-07-20 at 09:13 +0800, Joshua Lock wrote:
> On Thu, 2011-07-14 at 09:34 +0800, NiQingliang wrote:
> > new version
> >
> > diff --git a/oe-init-build-env b/oe-init-build-env
> > index 77332a7..0fe1b5e 100755
> > --- a/oe-init-build-env
> > +++ b/oe-init-build-env
> > @@ -39,6 +39,35 @@ else
> >     $OEROOT/scripts/oe-setup-builddir
> >     unset OEROOT
> >     unset BBPATH
> > +
> > +   # find the python 2.x, if the default python is not.
> > +   # NOTE:
> > +   #    the 'python -V' need redirect to stdout
> > +   #    once we can ensure every distribution has 'python2' (currently,
> > except
> > +   #    ubuntu), we should change bitbake's shebang to '/usr/bin/env
> > python2',
> > +   #    and remove this patch.
> > +   # precondition:
> > +   #    $BUILDDIR is not NULL, but I doubt when it will be NULL.
> > +   #    user have not made the file $BUILDDIR/python by himself.
> > +   if [ -z "`/usr/bin/env python -V 2>&1|grep '^Python 2\.'`" ]; then
> > +      echo "WARNING: your default python is not 2.x, so autodetect..."
> 
> I'm not sure we need to print this.
> 
> > +      PYTHON2_BIN=""
> > +      for PY_BIN in `find /{usr/,}bin -regex '.*/python\(\|2\|2\.[0-9]*
> > \)'`; do
> > +         if [ -n "`$PY_BIN -V 2>&1|grep '^Python 2\.'`" ]; then
> > +            PYTHON2_BIN=$PY_BIN
> > +            break
> > +         fi
> > +      done
> > +      if [ -n "$PYTHON2_BIN" ]; then
> > +         ln -sf $PY_BIN $BUILDDIR/python
> > +         export PATH="$BUILDDIR:$PATH"
> > +         echo "WARNING: poky will use '$PY_BIN' to execute python
> > code."
> 
> I can live without this message but if we do leave it in we should
> probably call it a NOTE rather than WARNING.
> 
> > +      else
> > +         echo "ERROR: poky can't find python 2.x."
> 
> Perhaps make this a little more informative?
> 
> ERROR: unable to find Python 2.x, BitBake requires Python 2.6 or 2.7.
> 
> > +      fi
> > +      unset PYTHON2_BIN
> > +   fi
> > +
> >     [ -n "$BUILDDIR" ] && cd $BUILDDIR
> >  fi
> 
> I can verify that this works as expected (i.e. does nothing) on my
> Fedora 15 machine with Python 2.7.1.
> 
> Could you submit the patch to the openembedded-core mailing list so that
> it can be considered for inclusion in the Yocto project's shared
> upstream?
> 
> Thanks,
> Joshua
> --
> Joshua Lock
>         Yocto Project "Johannes factotum"
>         Intel Open Source Technology Centre
> 

-- 
倪庆亮
TEL:    13588371863
E-MAIL: niqingliang@insigma.com.cn
BLOG:   http://niqingliang2003.wordpress.com

Re: Supporting upcoming distribution releases

[NiQingliang]

Oh, sorry, I have found the git tree of openembedded-core.


On Wed, 2011-07-20 at 10:31 +0800, NiQingliang wrote:
> update accroding your suggestion.
> This patch is for bitbake indeed, but bitbake is not part of
> openembedded. Is it RIGHT?
> 
> 
> diff --git a/oe-init-build-env b/oe-init-build-env
> index 77332a7..acf4e96 100755
> --- a/oe-init-build-env
> +++ b/oe-init-build-env
> @@ -39,6 +39,34 @@ else
>     $OEROOT/scripts/oe-setup-builddir
>     unset OEROOT
>     unset BBPATH
> +
> +   # find the python 2.x, if the default python is not.
> +   # NOTE:
> +   #    the 'python -V' need redirect to stdout
> +   #    once we can ensure every distribution has 'python2' (currently,
> except
> +   #    ubuntu), we should change bitbake's shebang to '/usr/bin/env
> python2',
> +   #    and remove this patch.
> +   # precondition:
> +   #    $BUILDDIR is not NULL, but I doubt when it will be NULL.
> +   #    user have not made the file $BUILDDIR/python by himself.
> +   if [ -z "`/usr/bin/env python -V 2>&1|grep '^Python 2\.'`" ]; then
> +      PYTHON2_BIN=""
> +      for PY_BIN in `find /{usr/,}bin -regex '.*/python\(\|2\|2\.[0-9]*
> \)'`; do
> +         if [ -n "`$PY_BIN -V 2>&1|grep '^Python 2\.'`" ]; then
> +            PYTHON2_BIN=$PY_BIN
> +            break
> +         fi
> +      done
> +      if [ -n "$PYTHON2_BIN" ]; then
> +         ln -sf $PY_BIN $BUILDDIR/python
> +         export PATH="$BUILDDIR:$PATH"
> +         echo "NOTE: poky will use '$PY_BIN' to execute python code."
> +      else
> +         echo "ERROR: unable to find Python 2.x, BitBake requires
> Python 2.6 or
> +      fi
> +      unset PYTHON2_BIN
> +   fi
> +
>     [ -n "$BUILDDIR" ] && cd $BUILDDIR
>  fi
> 
> 
> On Wed, 2011-07-20 at 09:13 +0800, Joshua Lock wrote:
> > On Thu, 2011-07-14 at 09:34 +0800, NiQingliang wrote:
> > > new version
> > >
> > > diff --git a/oe-init-build-env b/oe-init-build-env
> > > index 77332a7..0fe1b5e 100755
> > > --- a/oe-init-build-env
> > > +++ b/oe-init-build-env
> > > @@ -39,6 +39,35 @@ else
> > >     $OEROOT/scripts/oe-setup-builddir
> > >     unset OEROOT
> > >     unset BBPATH
> > > +
> > > +   # find the python 2.x, if the default python is not.
> > > +   # NOTE:
> > > +   #    the 'python -V' need redirect to stdout
> > > +   #    once we can ensure every distribution has 'python2' (currently,
> > > except
> > > +   #    ubuntu), we should change bitbake's shebang to '/usr/bin/env
> > > python2',
> > > +   #    and remove this patch.
> > > +   # precondition:
> > > +   #    $BUILDDIR is not NULL, but I doubt when it will be NULL.
> > > +   #    user have not made the file $BUILDDIR/python by himself.
> > > +   if [ -z "`/usr/bin/env python -V 2>&1|grep '^Python 2\.'`" ]; then
> > > +      echo "WARNING: your default python is not 2.x, so autodetect..."
> >
> > I'm not sure we need to print this.
> >
> > > +      PYTHON2_BIN=""
> > > +      for PY_BIN in `find /{usr/,}bin -regex '.*/python\(\|2\|2\.[0-9]*
> > > \)'`; do
> > > +         if [ -n "`$PY_BIN -V 2>&1|grep '^Python 2\.'`" ]; then
> > > +            PYTHON2_BIN=$PY_BIN
> > > +            break
> > > +         fi
> > > +      done
> > > +      if [ -n "$PYTHON2_BIN" ]; then
> > > +         ln -sf $PY_BIN $BUILDDIR/python
> > > +         export PATH="$BUILDDIR:$PATH"
> > > +         echo "WARNING: poky will use '$PY_BIN' to execute python
> > > code."
> >
> > I can live without this message but if we do leave it in we should
> > probably call it a NOTE rather than WARNING.
> >
> > > +      else
> > > +         echo "ERROR: poky can't find python 2.x."
> >
> > Perhaps make this a little more informative?
> >
> > ERROR: unable to find Python 2.x, BitBake requires Python 2.6 or 2.7.
> >
> > > +      fi
> > > +      unset PYTHON2_BIN
> > > +   fi
> > > +
> > >     [ -n "$BUILDDIR" ] && cd $BUILDDIR
> > >  fi
> >
> > I can verify that this works as expected (i.e. does nothing) on my
> > Fedora 15 machine with Python 2.7.1.
> >
> > Could you submit the patch to the openembedded-core mailing list so that
> > it can be considered for inclusion in the Yocto project's shared
> > upstream?
> >
> > Thanks,
> > Joshua
> > --
> > Joshua Lock
> >         Yocto Project "Johannes factotum"
> >         Intel Open Source Technology Centre
> >
> 
> --
> 倪庆亮
> TEL:    13588371863
> E-MAIL: niqingliang@insigma.com.cn
> BLOG:   http://niqingliang2003.wordpress.com
> 
> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

-- 
倪庆亮
TEL:    13588371863
E-MAIL: niqingliang@insigma.com.cn
BLOG:   http://niqingliang2003.wordpress.com

Re: Supporting upcoming distribution releases

[Xu, Jiajun]

> In our technical team call today we spent some time discussing how to
> support distribution releases that are due to happen around the time of Yocto 1.1.
> 
> Yocto 1.1 is scheduled for release on October 6th[1], the same month
> in which both Ubuntu and Fedora have new releases planned[2,3].
> OpenSUSE doesn't have a release scheduled until November 10th[4].
> 
> We should accommodate for these releases in our planning around 1.1 as
> we need to ensure that Yocto 1.1 can be used on the new versions of
> the chosen supported distros.
> 
> I had initially suggested we have people doing test and any relevant
> development around the beta cycles of Ubuntu and Fedora:
> 
> Fedora Beta (2011-09-20)
> Ubuntu (2011-09-01)
> In this time frame OpenSUSE will be on Milestone 5 (2011-09-01) which
> afaict (based on the 6th milestone being followed by an RC) should
> roughly equate to a beta.
> 
> However this aligns with our RC period at which point we may not want
> to accept large patches?
> 
> To meet our stabilise complete goal of August 29th we'd have to have
> people testing with:
> Fedora Alpha (2011-08-16)
> Ubuntu Alpha 3 (2011-08-04)
> OpenSUSE Milestone 4 (2011-08-11)
>

Thanks for the information, Josh.
I will add these into our test plan to make sure the above distribution(N+1) is validated.

> What are peoples thoughts on this? I think the onus for this testing
> will fall on engineers as the project QA is already pretty stretched.
> I have a tendency to update to early releases on at least one machine
> so will no doubt do some testing on Fedora but it would be nice to
> have a genuine strategy for this rather than relying on ad-hoc developer upgrades.
> 
> Final note: I'm left wondering if this emails contents also make sense
> as a wiki page?
> 
> Cheers,
> Joshua
> 
> 1. https://wiki.pokylinux.org/wiki/Yocto_1.1_Schedule
> 2. https://wiki.ubuntu.com/OneiricReleaseSchedule
> 3. http://fedoraproject.org/wiki/Releases/16/Schedule
> 4. http://en.opensuse.org/Roadmap

Best Regards,
Jiajun