Releases of BitBake to package for Fedora?

Releases of BitBake to package for Fedora?

[Neal Gompa]

Hey all,

Apologies if this is the wrong mailing list for this, but I'm looking
reintroduce BitBake into Fedora, but it seems like there hasn't been
releases in two years. I also cannot identify anywhere that provides
tarballs of BitBake to package.

Am I not looking in the right place?

I looked in the following locations:

* GitHub: https://github.com/openembedded/bitbake
* OE Git: http://git.openembedded.org/bitbake/
* Yocto downloads page: https://www.yoctoproject.org/downloads/tools

The Fedora package previously referenced snapshot tarballs generated
by tagged releases in OE Git, but there haven't been new tagged
releases in two years.

I'd appreciate any help here.

Thanks in advance and best regards!

-- 
真実はいつも一つ！/ Always, there's only one truth!

Re: Releases of BitBake to package for Fedora?

[Alexander Kanavin]

On 11/05/2017 05:09 PM, Neal Gompa wrote:
> Apologies if this is the wrong mailing list for this, but I'm looking
> reintroduce BitBake into Fedora, but it seems like there hasn't been
> releases in two years. I also cannot identify anywhere that provides
> tarballs of BitBake to package.

The correct place to ask is probably bitbake-devel list.

Alex

Re: Releases of BitBake to package for Fedora?

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 1712 bytes --]

The bitbake API isn't really stable and has a reasonable amount of change,
so if you were to package it then there's a good chance it would be out of
date within six months and people who wanted to use the latest oe-core
release against the packaged bitbake would hit API version errors.  The
recommended usage is to bundle in some way bitbake and the metadata
(combo-layer, submodules, repo, whatever).

As such there are no tarballs.  There are branches for each version and
commits where the version is bumped, if you're really determined to package
a snapshot.

Ross

On 5 November 2017 at 15:09, Neal Gompa <ngompa13@gmail.com> wrote:

> Hey all,
>
> Apologies if this is the wrong mailing list for this, but I'm looking
> reintroduce BitBake into Fedora, but it seems like there hasn't been
> releases in two years. I also cannot identify anywhere that provides
> tarballs of BitBake to package.
>
> Am I not looking in the right place?
>
> I looked in the following locations:
>
> * GitHub: https://github.com/openembedded/bitbake
> * OE Git: http://git.openembedded.org/bitbake/
> * Yocto downloads page: https://www.yoctoproject.org/downloads/tools
>
> The Fedora package previously referenced snapshot tarballs generated
> by tagged releases in OE Git, but there haven't been new tagged
> releases in two years.
>
> I'd appreciate any help here.
>
> Thanks in advance and best regards!
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 2681 bytes --]

Re: Releases of BitBake to package for Fedora?

[Andre McCurdy]

On Mon, Nov 6, 2017 at 3:33 AM, Burton, Ross <ross.burton@intel.com> wrote:
> The bitbake API isn't really stable and has a reasonable amount of change,
> so if you were to package it then there's a good chance it would be out of
> date within six months and people who wanted to use the latest oe-core
> release against the packaged bitbake would hit API version errors.  The
> recommended usage is to bundle in some way bitbake and the metadata
> (combo-layer, submodules, repo, whatever).
>
> As such there are no tarballs.  There are branches for each version and
> commits where the version is bumped, if you're really determined to package
> a snapshot.

If there's no realistic hope of (or need for) using bitbake standalone
then maybe it's time to move bitbake into oe-core?

Re: Releases of BitBake to package for Fedora?

[Paul Eggleton]

On Tuesday, 7 November 2017 8:16:06 AM NZDT Andre McCurdy wrote:
> On Mon, Nov 6, 2017 at 3:33 AM, Burton, Ross <ross.burton@intel.com> wrote:
> > The bitbake API isn't really stable and has a reasonable amount of change,
> > so if you were to package it then there's a good chance it would be out of
> > date within six months and people who wanted to use the latest oe-core
> > release against the packaged bitbake would hit API version errors.  The
> > recommended usage is to bundle in some way bitbake and the metadata
> > (combo-layer, submodules, repo, whatever).
> >
> > As such there are no tarballs.  There are branches for each version and
> > commits where the version is bumped, if you're really determined to
> > package a snapshot.
> 
> If there's no realistic hope of (or need for) using bitbake standalone
> then maybe it's time to move bitbake into oe-core?

Well, there are folks out there using bitbake with their own (non-OE) 
metadata, and that is absolutely supported, so even in the absence of stable 
releases of BitBake that distros could pick up the separation does still have 
a purpose.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Releases of BitBake to package for Fedora?

[Andre McCurdy]

On Mon, Nov 6, 2017 at 11:18 AM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> On Tuesday, 7 November 2017 8:16:06 AM NZDT Andre McCurdy wrote:
>> On Mon, Nov 6, 2017 at 3:33 AM, Burton, Ross <ross.burton@intel.com> wrote:
>> > The bitbake API isn't really stable and has a reasonable amount of change,
>> > so if you were to package it then there's a good chance it would be out of
>> > date within six months and people who wanted to use the latest oe-core
>> > release against the packaged bitbake would hit API version errors.  The
>> > recommended usage is to bundle in some way bitbake and the metadata
>> > (combo-layer, submodules, repo, whatever).
>> >
>> > As such there are no tarballs.  There are branches for each version and
>> > commits where the version is bumped, if you're really determined to
>> > package a snapshot.
>>
>> If there's no realistic hope of (or need for) using bitbake standalone
>> then maybe it's time to move bitbake into oe-core?
>
> Well, there are folks out there using bitbake with their own (non-OE)
> metadata,

Are any of those projects public? I'd be interested to see how that's
being done.

> and that is absolutely supported, so even in the absence of stable
> releases of BitBake that distros could pick up the separation does still have
> a purpose.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre

Re: Releases of BitBake to package for Fedora?

[Paul Eggleton]

On Tuesday, 7 November 2017 12:27:07 PM NZDT Andre McCurdy wrote:
> On Mon, Nov 6, 2017 at 11:18 AM, Paul Eggleton
> <paul.eggleton@linux.intel.com> wrote:
> > On Tuesday, 7 November 2017 8:16:06 AM NZDT Andre McCurdy wrote:
> >> On Mon, Nov 6, 2017 at 3:33 AM, Burton, Ross <ross.burton@intel.com> 
wrote:
> >> > The bitbake API isn't really stable and has a reasonable amount of 
change,
> >> > so if you were to package it then there's a good chance it would be out 
of
> >> > date within six months and people who wanted to use the latest oe-core
> >> > release against the packaged bitbake would hit API version errors.  The
> >> > recommended usage is to bundle in some way bitbake and the metadata
> >> > (combo-layer, submodules, repo, whatever).
> >> >
> >> > As such there are no tarballs.  There are branches for each version and
> >> > commits where the version is bumped, if you're really determined to
> >> > package a snapshot.
> >>
> >> If there's no realistic hope of (or need for) using bitbake standalone
> >> then maybe it's time to move bitbake into oe-core?
> >
> > Well, there are folks out there using bitbake with their own (non-OE)
> > metadata,
> 
> Are any of those projects public? I'd be interested to see how that's
> being done.

The main one I am aware of being active in recent times is Isar:

  https://github.com/ilbers/isar
  https://www.youtube.com/watch?v=GHHOxrtYBMc

There have been others mentioned on the bitbake mailing list over time but I 
don't recall any others that were public.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Releases of BitBake to package for Fedora?

[Neal Gompa]

Hey all,

I'm looking reintroduce BitBake into Fedora, but it seems like there
hasn't been releases in two years. I also cannot identify anywhere
that provides tarballs of BitBake to package.

The Fedora package previously referenced snapshot tarballs generated
by tagged releases in OE Git, but there haven't been new tagged
releases in two years.

I'd previously asked this on oe-core ML and was redirected to
bitbake-devel, so apologies to cross-list subs. But it was also
pointed out there that apparently BitBake has moved to a model where
they don't have stable points of releases, which seems rather odd for
a tool that is used by more than OpenEmbedded.

-- 
真実はいつも一つ！/ Always, there's only one truth!

Re: Releases of BitBake to package for Fedora?

[Paul Eggleton]

Hi Neal,

On Thursday, 9 November 2017 12:58:08 AM NZDT Neal Gompa wrote:
> I'm looking reintroduce BitBake into Fedora, but it seems like there
> hasn't been releases in two years. I also cannot identify anywhere
> that provides tarballs of BitBake to package.
> 
> The Fedora package previously referenced snapshot tarballs generated
> by tagged releases in OE Git, but there haven't been new tagged
> releases in two years.
> 
> I'd previously asked this on oe-core ML and was redirected to
> bitbake-devel, so apologies to cross-list subs. But it was also
> pointed out there that apparently BitBake has moved to a model where
> they don't have stable points of releases, which seems rather odd for
> a tool that is used by more than OpenEmbedded.

It's not that we don't have stable points - we do, it's that from the other 
side, each stable release of OE-Core is only tested with the corresponding 
stable release of BitBake, so if people start using BitBake from their distro 
we are probably going to have extra mismatch issues to deal with. We really 
ought to be tagging releases, not having done that is an oversight but it's 
reflective of the current typical usage.

It would be nice to get some exposure of BitBake as a standalone tool, and 
having it packaged by distros might be one way to help that, but my concern 
for OE usage would be that when this has been done in the past we have had 
situations where BitBake from the distro has been older than needed by OE-Core 
and users end up having to fetch it themselves anyway, so we'd have to have a 
strategy for handling that.

(This is not necessarily an official answer - I'd be interested to hear what 
RP and others have to say about it.)

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Releases of BitBake to package for Fedora?

[Neal Gompa]

On Wed, Nov 8, 2017 at 10:48 PM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> Hi Neal,
>
> On Thursday, 9 November 2017 12:58:08 AM NZDT Neal Gompa wrote:
>> I'm looking reintroduce BitBake into Fedora, but it seems like there
>> hasn't been releases in two years. I also cannot identify anywhere
>> that provides tarballs of BitBake to package.
>>
>> The Fedora package previously referenced snapshot tarballs generated
>> by tagged releases in OE Git, but there haven't been new tagged
>> releases in two years.
>>
>> I'd previously asked this on oe-core ML and was redirected to
>> bitbake-devel, so apologies to cross-list subs. But it was also
>> pointed out there that apparently BitBake has moved to a model where
>> they don't have stable points of releases, which seems rather odd for
>> a tool that is used by more than OpenEmbedded.
>
> It's not that we don't have stable points - we do, it's that from the other
> side, each stable release of OE-Core is only tested with the corresponding
> stable release of BitBake, so if people start using BitBake from their distro
> we are probably going to have extra mismatch issues to deal with. We really
> ought to be tagging releases, not having done that is an oversight but it's
> reflective of the current typical usage.
>
> It would be nice to get some exposure of BitBake as a standalone tool, and
> having it packaged by distros might be one way to help that, but my concern
> for OE usage would be that when this has been done in the past we have had
> situations where BitBake from the distro has been older than needed by OE-Core
> and users end up having to fetch it themselves anyway, so we'd have to have a
> strategy for handling that.
>
> (This is not necessarily an official answer - I'd be interested to hear what
> RP and others have to say about it.)
>

For what it's worth, if you guys are regularly tagging BitBake, this
can be automatically tracked in Fedora infrastructure and I can update
BitBake relatively quickly after that.

Unlike most distributions, it's usually not a problem to update
relatively frequently in Fedora. But that doesn't mean you should
stress me out with tons of releases out the wazoo. :)



-- 
真実はいつも一つ！/ Always, there's only one truth!

Re: Releases of BitBake to package for Fedora?

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 3069 bytes --]

There is also the opposite use case where people are using bitbake to build
intentionally older release of OE metadata and bitbake often isn't
backwards compatible. So as Paul said they need to use older release of
bitbake with older release of metadata and the latest version of bitbake
from their favorite distribution won't be compatible with it.

On Thu, Nov 9, 2017 at 4:53 AM, Neal Gompa <ngompa13@gmail.com> wrote:

> On Wed, Nov 8, 2017 at 10:48 PM, Paul Eggleton
> <paul.eggleton@linux.intel.com> wrote:
> > Hi Neal,
> >
> > On Thursday, 9 November 2017 12:58:08 AM NZDT Neal Gompa wrote:
> >> I'm looking reintroduce BitBake into Fedora, but it seems like there
> >> hasn't been releases in two years. I also cannot identify anywhere
> >> that provides tarballs of BitBake to package.
> >>
> >> The Fedora package previously referenced snapshot tarballs generated
> >> by tagged releases in OE Git, but there haven't been new tagged
> >> releases in two years.
> >>
> >> I'd previously asked this on oe-core ML and was redirected to
> >> bitbake-devel, so apologies to cross-list subs. But it was also
> >> pointed out there that apparently BitBake has moved to a model where
> >> they don't have stable points of releases, which seems rather odd for
> >> a tool that is used by more than OpenEmbedded.
> >
> > It's not that we don't have stable points - we do, it's that from the
> other
> > side, each stable release of OE-Core is only tested with the
> corresponding
> > stable release of BitBake, so if people start using BitBake from their
> distro
> > we are probably going to have extra mismatch issues to deal with. We
> really
> > ought to be tagging releases, not having done that is an oversight but
> it's
> > reflective of the current typical usage.
> >
> > It would be nice to get some exposure of BitBake as a standalone tool,
> and
> > having it packaged by distros might be one way to help that, but my
> concern
> > for OE usage would be that when this has been done in the past we have
> had
> > situations where BitBake from the distro has been older than needed by
> OE-Core
> > and users end up having to fetch it themselves anyway, so we'd have to
> have a
> > strategy for handling that.
> >
> > (This is not necessarily an official answer - I'd be interested to hear
> what
> > RP and others have to say about it.)
> >
>
> For what it's worth, if you guys are regularly tagging BitBake, this
> can be automatically tracked in Fedora infrastructure and I can update
> BitBake relatively quickly after that.
>
> Unlike most distributions, it's usually not a problem to update
> relatively frequently in Fedora. But that doesn't mean you should
> stress me out with tons of releases out the wazoo. :)
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> --
> _______________________________________________
> bitbake-devel mailing list
> bitbake-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/bitbake-devel
>

[-- Attachment #2: Type: text/html, Size: 4036 bytes --]