SSTATE_MIRRORS not working?

SSTATE_MIRRORS not working?

[Kristian Amlie]

For some time now, I've had the problem that SSTATE_MIRRORS does not
work properly for me. I can see that it downloads lots of packages from
the cache, but once the setscene stage is over, and runqueue begins, it
starts the whole build from scratch regardless.

This used to work for me before, it would only run a small subset of the
tasks locally, taking full advantage of the cache, so I'm fairly certain
my setup is correct. For me it broke maybe six weeks ago or so (master
branch).

I realize this question may be more appropriate for bitbake-devel, and I
can provide more details, but I thought I'd just hear if anybody else
has experienced the same, before I go digging.

-- 
Kristian

Re: SSTATE_MIRRORS not working?

[Richard Purdie]

On Fri, 2017-01-13 at 09:50 +0100, Kristian Amlie wrote:
> For some time now, I've had the problem that SSTATE_MIRRORS does not
> work properly for me. I can see that it downloads lots of packages
> from the cache, but once the setscene stage is over, and runqueue
> begins, it starts the whole build from scratch regardless.
> 
> This used to work for me before, it would only run a small subset of
> the tasks locally, taking full advantage of the cache, so I'm fairly
> certain my setup is correct. For me it broke maybe six weeks ago or
> so (master branch).
> 
> I realize this question may be more appropriate for bitbake-devel,
> and I can provide more details, but I thought I'd just hear if
> anybody else has experienced the same, before I go digging.

Which SSTATE_MIRRORS are you using?

The build logs should show what is being rebuilt. The autobuilder does
reuse sstate during its builds and we'd likely have noticed long build
times if it was completely broken so its likely some mismatch between
your setup and what is in the particular mirror you're using.

Cheers,

Richard

Re: SSTATE_MIRRORS not working?

[Kristian Amlie]

On 13/01/17 11:41, Richard Purdie wrote:
> On Fri, 2017-01-13 at 09:50 +0100, Kristian Amlie wrote:
>> For some time now, I've had the problem that SSTATE_MIRRORS does not
>> work properly for me. I can see that it downloads lots of packages
>> from the cache, but once the setscene stage is over, and runqueue
>> begins, it starts the whole build from scratch regardless.
>>
>> This used to work for me before, it would only run a small subset of
>> the tasks locally, taking full advantage of the cache, so I'm fairly
>> certain my setup is correct. For me it broke maybe six weeks ago or
>> so (master branch).
>>
>> I realize this question may be more appropriate for bitbake-devel,
>> and I can provide more details, but I thought I'd just hear if
>> anybody else has experienced the same, before I go digging.
> 
> Which SSTATE_MIRRORS are you using?

It's a private build machine in the cloud. It's simply the sstate-cache
folder exposed with Apache, and me pointing my mirror at it with:

  SSTATE_MIRRORS ?= "file://.* http://1.2.3.4/PATH"

> The build logs should show what is being rebuilt. The autobuilder does
> reuse sstate during its builds and we'd likely have noticed long build
> times if it was completely broken so its likely some mismatch between
> your setup and what is in the particular mirror you're using.

I'll try to do a more thorough check, and compare downloaded packages
with built packages.

-- 
Kristian

Re: SSTATE_MIRRORS not working?

[Kristian Amlie]

On 13/01/17 13:35, Kristian Amlie wrote:
> On 13/01/17 11:41, Richard Purdie wrote:
>> On Fri, 2017-01-13 at 09:50 +0100, Kristian Amlie wrote:
>>> For some time now, I've had the problem that SSTATE_MIRRORS does not
>>> work properly for me. I can see that it downloads lots of packages
>>> from the cache, but once the setscene stage is over, and runqueue
>>> begins, it starts the whole build from scratch regardless.
>>>
>>> This used to work for me before, it would only run a small subset of
>>> the tasks locally, taking full advantage of the cache, so I'm fairly
>>> certain my setup is correct. For me it broke maybe six weeks ago or
>>> so (master branch).
>>>
>>> I realize this question may be more appropriate for bitbake-devel,
>>> and I can provide more details, but I thought I'd just hear if
>>> anybody else has experienced the same, before I go digging.
>>
>> Which SSTATE_MIRRORS are you using?
> 
> It's a private build machine in the cloud. It's simply the sstate-cache
> folder exposed with Apache, and me pointing my mirror at it with:
> 
>   SSTATE_MIRRORS ?= "file://.* http://1.2.3.4/PATH"
> 
>> The build logs should show what is being rebuilt. The autobuilder does
>> reuse sstate during its builds and we'd likely have noticed long build
>> times if it was completely broken so its likely some mismatch between
>> your setup and what is in the particular mirror you're using.
> 
> I'll try to do a more thorough check, and compare downloaded packages
> with built packages.

Looker closer, it appears that it's all the native tools that are
rebuilt. This didn't use to happen though. What could be the difference
factor here?

My machine is Ubuntu 16.04 and the cloud machine I use as a mirror is
Debian 8. Could this be significant?

-- 
Kristian

Re: SSTATE_MIRRORS not working?

[Joshua Lock]

On Fri, 2017-01-13 at 15:58 +0100, Kristian Amlie wrote:
> On 13/01/17 13:35, Kristian Amlie wrote:
> > On 13/01/17 11:41, Richard Purdie wrote:
> > > On Fri, 2017-01-13 at 09:50 +0100, Kristian Amlie wrote:
> > > > For some time now, I've had the problem that SSTATE_MIRRORS
> > > > does not
> > > > work properly for me. I can see that it downloads lots of
> > > > packages
> > > > from the cache, but once the setscene stage is over, and
> > > > runqueue
> > > > begins, it starts the whole build from scratch regardless.
> > > > 
> > > > This used to work for me before, it would only run a small
> > > > subset of
> > > > the tasks locally, taking full advantage of the cache, so I'm
> > > > fairly
> > > > certain my setup is correct. For me it broke maybe six weeks
> > > > ago or
> > > > so (master branch).
> > > > 
> > > > I realize this question may be more appropriate for bitbake-
> > > > devel,
> > > > and I can provide more details, but I thought I'd just hear if
> > > > anybody else has experienced the same, before I go digging.
> > > 
> > > Which SSTATE_MIRRORS are you using?
> > 
> > It's a private build machine in the cloud. It's simply the sstate-
> > cache
> > folder exposed with Apache, and me pointing my mirror at it with:
> > 
> >   SSTATE_MIRRORS ?= "file://.* http://1.2.3.4/PATH"
> > 
> > > The build logs should show what is being rebuilt. The autobuilder
> > > does
> > > reuse sstate during its builds and we'd likely have noticed long
> > > build
> > > times if it was completely broken so its likely some mismatch
> > > between
> > > your setup and what is in the particular mirror you're using.
> > 
> > I'll try to do a more thorough check, and compare downloaded
> > packages
> > with built packages.
> 
> Looker closer, it appears that it's all the native tools that are
> rebuilt. This didn't use to happen though. What could be the
> difference
> factor here?

Did you recently change distro (i.e. was using poky and switched to a
custom distro)? Does your distro use uninative?

http://www.yoctoproject.org/docs/2.2/mega-manual/mega-manual.html#ref-c
lasses-uninative

> My machine is Ubuntu 16.04 and the cloud machine I use as a mirror is
> Debian 8. Could this be significant?

If you aren't using uninative the different host OS won't share sstate
for native recipe variants.

Regards,

Joshua