Why is "bitbake core-image-minimal" building gtk docs?

Why is "bitbake core-image-minimal" building gtk docs?

[Laszlo Papp]

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

Hi,

alternatively: is there an option to turn gtk, especially the docs off?

Cheers,
Laszlo

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

Re: Why is "bitbake core-image-minimal" building gtk docs?

[Jack Mitchell]

On 16/08/13 12:40, Laszlo Papp wrote:
> Hi,
> 
> alternatively: is there an option to turn gtk, especially the docs off?
> 
> Cheers,
> Laszlo
> 
> 

I don't know how to properly stop it building, or turn it off but I can
tell you the cause.

Running bitbake -g core-image-minimal outputs the dependency graphs, and
by examining that it seems as though the following packages pull in
gtk-doc related packages.

"connman" -> "gtk-doc-stub-native"
"kmod-native" -> "gtk-doc-stub-native"
"kmod" -> "gtk-doc-stub-native"
"glib-2.0" -> "gtk-doc-stub-native"
"glib-2.0-native" -> "gtk-doc-stub-native"

Now, all these packages are gtk-doc-stub[-native], which is described as:

DESCRIPTION = "Stub implementation of gtk-doc, as we don't want to build
the API documentation"

So it sounds like gtk-docs aren't actually being built, but the stubs
provide enough to make the package think they're being built...

That's all I know, someone with more gtk knowledge than me can probably
fill in the reason for why it's required to build those packages.

Cheers,

-- 
  Jack Mitchell (jack@embed.me.uk)
  Embedded Systems Engineer
  Cambrideshire, UK
  http://www.embed.me.uk
--

Re: Why is "bitbake core-image-minimal" building gtk docs?

[Laszlo Papp]

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

Ping?


On Fri, Aug 16, 2013 at 1:15 PM, Jack Mitchell <ml@communistcode.co.uk>wrote:

> On 16/08/13 12:40, Laszlo Papp wrote:
> > Hi,
> >
> > alternatively: is there an option to turn gtk, especially the docs off?
> >
> > Cheers,
> > Laszlo
> >
> >
>
> I don't know how to properly stop it building, or turn it off but I can
> tell you the cause.
>
> Running bitbake -g core-image-minimal outputs the dependency graphs, and
> by examining that it seems as though the following packages pull in
> gtk-doc related packages.
>
> "connman" -> "gtk-doc-stub-native"
> "kmod-native" -> "gtk-doc-stub-native"
> "kmod" -> "gtk-doc-stub-native"
> "glib-2.0" -> "gtk-doc-stub-native"
> "glib-2.0-native" -> "gtk-doc-stub-native"
>
> Now, all these packages are gtk-doc-stub[-native], which is described as:
>
> DESCRIPTION = "Stub implementation of gtk-doc, as we don't want to build
> the API documentation"
>
> So it sounds like gtk-docs aren't actually being built, but the stubs
> provide enough to make the package think they're being built...
>
> That's all I know, someone with more gtk knowledge than me can probably
> fill in the reason for why it's required to build those packages.
>
> Cheers,
>
> --
>   Jack Mitchell (jack@embed.me.uk)
>   Embedded Systems Engineer
>   Cambrideshire, UK
>   http://www.embed.me.uk
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

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

Re: Why is "bitbake core-image-minimal" building gtk docs?

[Jack Mitchell]

On 21/08/13 08:55, Laszlo Papp wrote:
> Ping?
> 
> 
> On Fri, Aug 16, 2013 at 1:15 PM, Jack Mitchell <ml@communistcode.co.uk
> <mailto:ml@communistcode.co.uk>> wrote:
> 
>     On 16/08/13 12:40, Laszlo Papp wrote:
>     > Hi,
>     >
>     > alternatively: is there an option to turn gtk, especially the docs
>     off?
>     >
>     > Cheers,
>     > Laszlo
>     >
>     >
> 
>     I don't know how to properly stop it building, or turn it off but I can
>     tell you the cause.
> 
>     Running bitbake -g core-image-minimal outputs the dependency graphs, and
>     by examining that it seems as though the following packages pull in
>     gtk-doc related packages.
> 
>     "connman" -> "gtk-doc-stub-native"
>     "kmod-native" -> "gtk-doc-stub-native"
>     "kmod" -> "gtk-doc-stub-native"
>     "glib-2.0" -> "gtk-doc-stub-native"
>     "glib-2.0-native" -> "gtk-doc-stub-native"
> 
>     Now, all these packages are gtk-doc-stub[-native], which is
>     described as:
> 
>     DESCRIPTION = "Stub implementation of gtk-doc, as we don't want to build
>     the API documentation"
> 
>     So it sounds like gtk-docs aren't actually being built, but the stubs
>     provide enough to make the package think they're being built...
> 
>     That's all I know, someone with more gtk knowledge than me can probably
>     fill in the reason for why it's required to build those packages.
> 
>     Cheers,
> 

Having a quick look around it seems as though glib can be built with
docs disabled:

--disable-gtk-doc and --enable-gtk-doc.  By default the configure script
will try to auto-detect whether the gtk-doc package is installed. If it
is, then it will use it to extract and build the documentation for the
GLib library. These options can be used to explicitly control whether
gtk-doc should be used or not. If it is not used, the distributed,
pre-generated HTML files will be installed instead of building them on
your machine.

the glib-2.0 recipe inherits gtk-doc, but doesn't disable it anywhere. I
imagine that you could add --disable-gtk-doc and remove the gtk-doc
inherit to stop glib-2.0 requiring the stub.

It seems here: http://patches.openembedded.org/patch/32567/

gtk-doc was specifically added back into the connman build.

kmod also has a --disable-gtk-doc configure option.

Here is the patch which kicks it all off:

http://lists.linuxtogo.org/pipermail/openembedded-core/2012-July/026077.html

So, make of this what you will. I've cc'd Ross in to see if he has a
specific reason for re-enabling gkt-doc in some packages. Maybe we
should turn it into an image feature...?

Regardless of all this though, it seems the packages will ship with docs
anyway, just pre-built HTML ones, so is it worth it?

-- 
  Jack Mitchell (jack@embed.me.uk)
  Embedded Systems Engineer
  Cambrideshire, UK
  http://www.embed.me.uk
--

Re: Why is "bitbake core-image-minimal" building gtk docs?

[Burton, Ross]

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

On 21 August 2013 09:40, Jack Mitchell <ml@communistcode.co.uk> wrote:

> Here is the patch which kicks it all off:
>
>
> http://lists.linuxtogo.org/pipermail/openembedded-core/2012-July/026077.html
>
> So, make of this what you will. I've cc'd Ross in to see if he has a
> specific reason for re-enabling gkt-doc in some packages. Maybe we
> should turn it into an image feature...?
>

tl;dr: it's a stub package, you're not building any gtk-doc, and you can't
turn it on if you wanted to.

There's some confusion in this thread, so I'll try and clear it up.

We need to build gtk-doc (or compatible) because it provides m4 autoconf
fragments that are needed at configure time by any package that uses
gtk-doc for documentation.  Previously we were patching recipes one by one
to disable the rules, but that's prone to failure.  We integrated
gtk-doc-stub (also used by gnome-os) which has the same external interfaces
but is entirely stubs, for example:

https://git.gnome.org/browse/gtk-doc-stub/tree/gtk-doc.m4

This way we can actually configure everything that uses gtk-doc without
needing the full gtk-doc package.

There is a gtk-doc class which adds a dependency on gtk-doc-stub-native and
then adds --disable-gtk-doc to EXTRA_OECONF.  This is why the explicit
--disable was removed from connman: it was redundant.

The other advantage of using a central gtk-doc class is that if someone did
want to build gtk-doc, they would just need to package up the real gtk-doc
and change the class.

Ross

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

Re: Why is "bitbake core-image-minimal" building gtk docs?

[Laszlo Papp]

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

Having had an inconvenient debugging session this morning with the help of
you, ndec, and so forth on IRC, I would propose to get rid of this gtk doc
stub, at least how it is now. It is completely breaking projects causing
regressions compared to denzil. We are pretty much blocked by it altogether
now. Here is the other thread for details:
https://lists.yoctoproject.org/pipermail/poky/2013-August/009184.html

IMHO, there should be a way for end users to get rid of the blocker issue
and regression. So, how about making this optional?


On Wed, Aug 21, 2013 at 11:04 AM, Burton, Ross <ross.burton@intel.com>wrote:

> On 21 August 2013 09:40, Jack Mitchell <ml@communistcode.co.uk> wrote:
>
>> Here is the patch which kicks it all off:
>>
>>
>> http://lists.linuxtogo.org/pipermail/openembedded-core/2012-July/026077.html
>>
>> So, make of this what you will. I've cc'd Ross in to see if he has a
>> specific reason for re-enabling gkt-doc in some packages. Maybe we
>> should turn it into an image feature...?
>>
>
> tl;dr: it's a stub package, you're not building any gtk-doc, and you can't
> turn it on if you wanted to.
>
> There's some confusion in this thread, so I'll try and clear it up.
>
> We need to build gtk-doc (or compatible) because it provides m4 autoconf
> fragments that are needed at configure time by any package that uses
> gtk-doc for documentation.  Previously we were patching recipes one by one
> to disable the rules, but that's prone to failure.  We integrated
> gtk-doc-stub (also used by gnome-os) which has the same external interfaces
> but is entirely stubs, for example:
>
> https://git.gnome.org/browse/gtk-doc-stub/tree/gtk-doc.m4
>
> This way we can actually configure everything that uses gtk-doc without
> needing the full gtk-doc package.
>
> There is a gtk-doc class which adds a dependency on gtk-doc-stub-native
> and then adds --disable-gtk-doc to EXTRA_OECONF.  This is why the explicit
> --disable was removed from connman: it was redundant.
>
> The other advantage of using a central gtk-doc class is that if someone
> did want to build gtk-doc, they would just need to package up the real
> gtk-doc and change the class.
>
> Ross
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>

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

Re: Why is "bitbake core-image-minimal" building gtk docs?

[Burton, Ross]

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

On 21 August 2013 11:16, Laszlo Papp <lpapp@kde.org> wrote:

> Having had an inconvenient debugging session this morning with the help of
> you, ndec, and so forth on IRC, I would propose to get rid of this gtk doc
> stub, at least how it is now. It is completely breaking projects causing
> regressions compared to denzil. We are pretty much blocked by it altogether
> now. Here is the other thread for details:
> https://lists.yoctoproject.org/pipermail/poky/2013-August/009184.html
>
> IMHO, there should be a way for end users to get rid of the blocker issue
> and regression. So, how about making this optional?
>

We used to patch each recipe individually and it wasn't pleasant.
 gtk-doc-stub is just the first place you're hitting problems with putting
DL_DIR inside a git repository, removing it will cause something else to
break.

Ross

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

Re: Why is "bitbake core-image-minimal" building gtk docs?

[Laszlo Papp]

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

I am not saying to fix gtk-doc-stub only. I am saying fix the nastiness of
using git repositories for released and supposedly stable versions. I do
not see why tarball would not be enough for those to work off-hand? That
should be the ideal architecture IMHO.


On Wed, Aug 21, 2013 at 11:21 AM, Burton, Ross <ross.burton@intel.com>wrote:

> On 21 August 2013 11:16, Laszlo Papp <lpapp@kde.org> wrote:
>
>> Having had an inconvenient debugging session this morning with the help
>> of you, ndec, and so forth on IRC, I would propose to get rid of this gtk
>> doc stub, at least how it is now. It is completely breaking projects
>> causing regressions compared to denzil. We are pretty much blocked by it
>> altogether now. Here is the other thread for details:
>> https://lists.yoctoproject.org/pipermail/poky/2013-August/009184.html
>>
>> IMHO, there should be a way for end users to get rid of the blocker issue
>> and regression. So, how about making this optional?
>>
>
> We used to patch each recipe individually and it wasn't pleasant.
>  gtk-doc-stub is just the first place you're hitting problems with putting
> DL_DIR inside a git repository, removing it will cause something else to
> break.
>
> Ross
>

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

Re: Why is "bitbake core-image-minimal" building gtk docs?

[Burton, Ross]

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

On 21 August 2013 11:24, Laszlo Papp <lpapp@kde.org> wrote:

> I am not saying to fix gtk-doc-stub only. I am saying fix the nastiness of
> using git repositories for released and supposedly stable versions. I do
> not see why tarball would not be enough for those to work off-hand? That
> should be the ideal architecture IMHO.
>

Two good reasons to allow git repositories as a source:

1) Many projects don't make tarball releases.
2) It's incredibly useful to be able to build from git snapshots for
development/testing purposes.

What you're asking for is the inability to use git repositories in SRC_URI,
which won't happen.

Ross

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

Re: Why is "bitbake core-image-minimal" building gtk docs?

[Laszlo Papp]

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

On Wed, Aug 21, 2013 at 11:26 AM, Burton, Ross <ross.burton@intel.com>wrote:

> On 21 August 2013 11:24, Laszlo Papp <lpapp@kde.org> wrote:
>
>> I am not saying to fix gtk-doc-stub only. I am saying fix the nastiness
>> of using git repositories for released and supposedly stable versions. I do
>> not see why tarball would not be enough for those to work off-hand? That
>> should be the ideal architecture IMHO.
>>
>
> Two good reasons to allow git repositories as a source:
>
> 1) Many projects don't make tarball releases.
>

That does not mean bitbake cannot generate tarball out of the git
repository. In fact, it is relatively simple. ;-)


> 2) It's incredibly useful to be able to build from git snapshots for
> development/testing purposes.
>

I was explicitly mentioning stable and official released variants.

What you're asking for is the inability to use git repositories in SRC_URI,
> which won't happen.
>

No, that is not what I am asking.

Here you can find the feature request:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5035

Cheers, L.

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

Re: Why is "bitbake core-image-minimal" building gtk docs?

[Martin Jansa]

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

On Wed, Aug 21, 2013 at 11:31:53AM +0100, Laszlo Papp wrote:
> On Wed, Aug 21, 2013 at 11:26 AM, Burton, Ross <ross.burton@intel.com>wrote:
> 
> > On 21 August 2013 11:24, Laszlo Papp <lpapp@kde.org> wrote:
> >
> >> I am not saying to fix gtk-doc-stub only. I am saying fix the nastiness
> >> of using git repositories for released and supposedly stable versions. I do
> >> not see why tarball would not be enough for those to work off-hand? That
> >> should be the ideal architecture IMHO.
> >>
> >
> > Two good reasons to allow git repositories as a source:
> >
> > 1) Many projects don't make tarball releases.
> >
> 
> That does not mean bitbake cannot generate tarball out of the git
> repository. In fact, it is relatively simple. ;-)

It does, all you need to do is enable BB_GENERATE_MIRROR_TARBALLS

Versioned tarballs are already tracked by
https://bugzilla.yoctoproject.org/show_bug.cgi?id=1511

> > 2) It's incredibly useful to be able to build from git snapshots for
> > development/testing purposes.
> >
> 
> I was explicitly mentioning stable and official released variants.
> 
> What you're asking for is the inability to use git repositories in SRC_URI,
> > which won't happen.
> >
> 
> No, that is not what I am asking.
> 
> Here you can find the feature request:
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=5035
> 
> Cheers, L.

> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: Why is "bitbake core-image-minimal" building gtk docs?

[Laszlo Papp]

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

On Wed, Aug 21, 2013 at 12:04 PM, Martin Jansa <martin.jansa@gmail.com>wrote:

> On Wed, Aug 21, 2013 at 11:31:53AM +0100, Laszlo Papp wrote:
> > That does not mean bitbake cannot generate tarball out of the git
> > repository. In fact, it is relatively simple. ;-)
>
> It does, all you need to do is enable BB_GENERATE_MIRROR_TARBALLS
>

I am not using mirrors. I am simply pushing the downloads folder, etc to
the git repository "git add". It is as simply as that without an explicit
mirror set up and its maintenance.

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

Re: Why is "bitbake core-image-minimal" building gtk docs?

[Richard Purdie]

On Wed, 2013-08-21 at 12:10 +0100, Laszlo Papp wrote:
> On Wed, Aug 21, 2013 at 12:04 PM, Martin Jansa
> <martin.jansa@gmail.com> wrote:
>         On Wed, Aug 21, 2013 at 11:31:53AM +0100, Laszlo Papp wrote:
>         > That does not mean bitbake cannot generate tarball out of
>         the git
>         > repository. In fact, it is relatively simple. ;-)
>
>         It does, all you need to do is enable
>         BB_GENERATE_MIRROR_TARBALLS
>
> I am not using mirrors. I am simply pushing the downloads folder, etc
> to the git repository "git add". It is as simply as that without an
> explicit mirror set up and its maintenance.

Regardless of whether you use mirrors or not, if you set
BB_GENERATE_MIRROR_TARBALLS it will create tarballs in DL_DIR of the git
repositories. You can then stop trying to check in the /git/  and /git2/
subdirectories of DL_DIR and some of your problems will likely go away.

The reason this is not enabled by default is for performance reasons.

Cheers,

Richard

Re: Why is "bitbake core-image-minimal" building gtk docs?

[Laszlo Papp]

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

OK, so the bugreport has to be changed to a documentation issue about it.
At least, reading the short bits about it that exist whispered that to me,
it would not be useful without a mirror.


On Wed, Aug 21, 2013 at 3:59 PM, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> On Wed, 2013-08-21 at 12:10 +0100, Laszlo Papp wrote:
> > On Wed, Aug 21, 2013 at 12:04 PM, Martin Jansa
> > <martin.jansa@gmail.com> wrote:
> >         On Wed, Aug 21, 2013 at 11:31:53AM +0100, Laszlo Papp wrote:
> >         > That does not mean bitbake cannot generate tarball out of
> >         the git
> >         > repository. In fact, it is relatively simple. ;-)
> >
> >         It does, all you need to do is enable
> >         BB_GENERATE_MIRROR_TARBALLS
> >
> > I am not using mirrors. I am simply pushing the downloads folder, etc
> > to the git repository "git add". It is as simply as that without an
> > explicit mirror set up and its maintenance.
>
> Regardless of whether you use mirrors or not, if you set
> BB_GENERATE_MIRROR_TARBALLS it will create tarballs in DL_DIR of the git
> repositories. You can then stop trying to check in the /git/  and /git2/
> subdirectories of DL_DIR and some of your problems will likely go away.
>
> The reason this is not enabled by default is for performance reasons.
>
> Cheers,
>
> Richard
>
>

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

Re: Why is "bitbake core-image-minimal" building gtk docs?

[Laszlo Papp]

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

On Wed, Aug 21, 2013 at 3:59 PM, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> Regardless of whether you use mirrors or not, if you set
> BB_GENERATE_MIRROR_TARBALLS it will create tarballs in DL_DIR of the git
> repositories. You can then stop trying to check in the /git/  and /git2/
> subdirectories of DL_DIR and some of your problems will likely go away.
>

Actually, I have just spent one hour with a full rebuild, but putting this
variable into the local.conf did not generate any different downloads
folder. Any other idea how to get rid of the git hassle in here without a
major infrastructure refactor?

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

Re: Why is "bitbake core-image-minimal" building gtk docs?

[Laszlo Papp]

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

On Thu, Aug 29, 2013 at 5:19 PM, Laszlo Papp <lpapp@kde.org> wrote:

> On Wed, Aug 21, 2013 at 3:59 PM, Richard Purdie <
> richard.purdie@linuxfoundation.org> wrote:
>
>> Regardless of whether you use mirrors or not, if you set
>>  BB_GENERATE_MIRROR_TARBALLS it will create tarballs in DL_DIR of the git
>> repositories. You can then stop trying to check in the /git/  and /git2/
>> subdirectories of DL_DIR and some of your problems will likely go away.
>>
>
> Actually, I have just spent one hour with a full rebuild, but putting this
> variable into the local.conf did not generate any different downloads
> folder. Any other idea how to get rid of the git hassle in here without a
> major infrastructure refactor?
>

What I executed was:  "git rm -r ./downloads/git2 && git commit
./downloads/git2". Even after that, it is broken. :(

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

Re: Why is "bitbake core-image-minimal" building gtk docs?

[Laszlo Papp]

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

OK, it seems to finally work on our CI. Thanks to all for the help.


On Thu, Aug 29, 2013 at 6:15 PM, Laszlo Papp <lpapp@kde.org> wrote:

> On Thu, Aug 29, 2013 at 5:19 PM, Laszlo Papp <lpapp@kde.org> wrote:
>
>> On Wed, Aug 21, 2013 at 3:59 PM, Richard Purdie <
>> richard.purdie@linuxfoundation.org> wrote:
>>
>>> Regardless of whether you use mirrors or not, if you set
>>>  BB_GENERATE_MIRROR_TARBALLS it will create tarballs in DL_DIR of the git
>>> repositories. You can then stop trying to check in the /git/  and /git2/
>>> subdirectories of DL_DIR and some of your problems will likely go away.
>>>
>>
>> Actually, I have just spent one hour with a full rebuild, but putting
>> this variable into the local.conf did not generate any different downloads
>> folder. Any other idea how to get rid of the git hassle in here without a
>> major infrastructure refactor?
>>
>
> What I executed was:  "git rm -r ./downloads/git2 && git commit
> ./downloads/git2". Even after that, it is broken. :(
>
>

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

Re: Why is "bitbake core-image-minimal" building gtk docs?

[Laszlo Papp]

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

On Wed, Aug 21, 2013 at 12:04 PM, Martin Jansa <martin.jansa@gmail.com>wrote:

> It does, all you need to do is enable BB_GENERATE_MIRROR_TARBALLS
>

I need all the three lines or just the last?

 SOURCE_MIRROR_URL ?= "file://${DL_DIR}"
 INHERIT += "own-mirrors"
 BB_GENERATE_MIRROR_TARBALLS = "1"

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

Re: Why is "bitbake core-image-minimal" building gtk docs?

[Martin Jansa]

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

On Thu, Aug 29, 2013 at 04:01:20PM +0100, Laszlo Papp wrote:
> On Wed, Aug 21, 2013 at 12:04 PM, Martin Jansa <martin.jansa@gmail.com>wrote:
> 
> > It does, all you need to do is enable BB_GENERATE_MIRROR_TARBALLS
> >
> 
> I need all the three lines or just the last?
> 
>  SOURCE_MIRROR_URL ?= "file://${DL_DIR}"
>  INHERIT += "own-mirrors"
>  BB_GENERATE_MIRROR_TARBALLS = "1"

Depends on what you're trying to do, BB_GENERATE_MIRROR_TARBALLS just
generates tarballs from SCM checkouts.

SOURCE_MIRROR_URL ?= "file://${DL_DIR}" doesn't look correct (DL_DIR is
used by default), SOURCE_MIRROR_URL + own-mirrors are useful on other
builders which will be using the generated mirror (over http:// or
smb/nfs etc - with file://mount-point/foo)

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]