All of lore.kernel.org
 help / color / mirror / Atom feed
* Removing 7844358 from toaster-next ("create Build object earlier in bitbake processing")
@ 2016-04-04  8:24 Smith, Elliot
  2016-04-04 16:32 ` Michael Wood
  0 siblings, 1 reply; 3+ messages in thread
From: Smith, Elliot @ 2016-04-04  8:24 UTC (permalink / raw)
  To: toaster

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

We currently have this in toaster-next, but after discussion with RP, we've
agreed that this is probably not the right way to do this.

RP suggested a couple of alternatives, which I can look into this week (see
bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=8440).

For the moment, can I suggest that we remove this from toaster-next and
force push the branch?

NOTE: I'm mentioning this because it will mess up everyone's Toaster
database, as the patch included a migration. You'll need to remove any
existing db and start again. It will also affect Ed's branch, as he rebased
on toaster-next with this patch in it.

There is also a patch created by Michael which fixed an issue with my
patch, which I submitted to bitbake-devel last week. This failed to apply
because 7844358 wasn't accepted.

So this patch should also be ignored for now:
http://lists.openembedded.org/pipermail/bitbake-devel/2016-April/007258.html
I have already removed it from toaster-next.

Details of the commit I plan to remove are below for reference.

Elliot


commit 78443585bc92eca7140267126d53f749be3cdd6a
Author: Elliot Smith <elliot.smith@intel.com>
Date:   Thu Jan 28 16:21:01 2016 +0000

    toaster: create Build object earlier in bitbake processing

    If a build fails because of a bitbake error occurring before the
    BuildStarted event fires, we do not generate a Build object
    for command-line builds. This means that failed command-line builds
    don't appear in Toaster at all.

    To resolve, split build creation into two steps:

    1. Just before buildTargets() is invoked on the XMLRPC server: create
    the base Build object. Note that as soon as a Toaster-triggered
    build starts, targets are added to it; but this event is the earliest
    point when task and targets are available for command-line builds.
    (This requires a new TargetsAcquired event to be fired by the XMLRPC
    server when the buildTargets() command is called.)

    2. BuildStarted event: add any layer information to either type of build
    (command-line or Toaster-triggered).

    Note that the build_name property cannot be set until BuildStarted,
    as it is not available until then, which could cause problems
    for creating Build objects earlier; however, this property is
    redundant, as it's never used anywhere in Toaster, so it has been
    removed (along with any functions which refer to it).

    [YOCTO #8440]

    Signed-off-by: Elliot Smith <elliot.smith@intel.com>
    Signed-off-by: Michael Wood <michael.g.wood@intel.com>


-- 
Elliot Smith
Software Engineer
Intel Open Source Technology Centre

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Removing 7844358 from toaster-next ("create Build object earlier in bitbake processing")
  2016-04-04  8:24 Removing 7844358 from toaster-next ("create Build object earlier in bitbake processing") Smith, Elliot
@ 2016-04-04 16:32 ` Michael Wood
  2016-04-05 10:10   ` Smith, Elliot
  0 siblings, 1 reply; 3+ messages in thread
From: Michael Wood @ 2016-04-04 16:32 UTC (permalink / raw)
  To: toaster

Yes, let's remove  "toaster: create Build object earlier in bitbake 
processing" from toaster-next. If it's not going up to bitbake-devel in 
it's current form and It's causing a regression there isn't any point 
keeping it around in toaster-next.

Michael

On 04/04/16 09:24, Smith, Elliot wrote:
> We currently have this in toaster-next, but after discussion with RP, 
> we've agreed that this is probably not the right way to do this.
>
> RP suggested a couple of alternatives, which I can look into this week 
> (see bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=8440).
>
> For the moment, can I suggest that we remove this from toaster-next 
> and force push the branch?
>
> NOTE: I'm mentioning this because it will mess up everyone's Toaster 
> database, as the patch included a migration. You'll need to remove any 
> existing db and start again. It will also affect Ed's branch, as he 
> rebased on toaster-next with this patch in it.
>
> There is also a patch created by Michael which fixed an issue with my 
> patch, which I submitted to bitbake-devel last week. This failed to 
> apply because 7844358 wasn't accepted.
>
> So this patch should also be ignored for now:
> http://lists.openembedded.org/pipermail/bitbake-devel/2016-April/007258.html
> I have already removed it from toaster-next.
>
> Details of the commit I plan to remove are below for reference.
>
> Elliot
>
>
> commit 78443585bc92eca7140267126d53f749be3cdd6a
> Author: Elliot Smith <elliot.smith@intel.com 
> <mailto:elliot.smith@intel.com>>
> Date:   Thu Jan 28 16:21:01 2016 +0000
>
>     toaster: create Build object earlier in bitbake processing
>     If a build fails because of a bitbake error occurring before the
>     BuildStarted event fires, we do not generate a Build object
>     for command-line builds. This means that failed command-line builds
>     don't appear in Toaster at all.
>     To resolve, split build creation into two steps:
>     1. Just before buildTargets() is invoked on the XMLRPC server: create
>     the base Build object. Note that as soon as a Toaster-triggered
>     build starts, targets are added to it; but this event is the earliest
>     point when task and targets are available for command-line builds.
>     (This requires a new TargetsAcquired event to be fired by the XMLRPC
>     server when the buildTargets() command is called.)
>     2. BuildStarted event: add any layer information to either type of 
> build
>     (command-line or Toaster-triggered).
>     Note that the build_name property cannot be set until BuildStarted,
>     as it is not available until then, which could cause problems
>     for creating Build objects earlier; however, this property is
>     redundant, as it's never used anywhere in Toaster, so it has been
>     removed (along with any functions which refer to it).
>     [YOCTO #8440]
>     Signed-off-by: Elliot Smith <elliot.smith@intel.com 
> <mailto:elliot.smith@intel.com>>
>     Signed-off-by: Michael Wood <michael.g.wood@intel.com 
> <mailto:michael.g.wood@intel.com>>
>
>
> -- 
> Elliot Smith
> Software Engineer
> Intel Open Source Technology Centre
>
>



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Removing 7844358 from toaster-next ("create Build object earlier in bitbake processing")
  2016-04-04 16:32 ` Michael Wood
@ 2016-04-05 10:10   ` Smith, Elliot
  0 siblings, 0 replies; 3+ messages in thread
From: Smith, Elliot @ 2016-04-05 10:10 UTC (permalink / raw)
  To: Michael Wood, Ed Bartosh; +Cc: toaster

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

I've now removed "toaster: create Build object earlier in bitbake
processing" from toaster-next (and rebased on master).

I've tested cli builds and Toaster builds, and both appear to be working
correctly.

Note that if you're using toaster-next, you will need to remove your
database and recreate it (due to changes to migrations which have now been
pulled).

Ed's branch (ed/toaster/project-build-dir-cancel-dldir_sstatedir) includes
3 commits which are rendered obsolete by this change (oldest first):

020919b toaster: create Build object earlier in bitbake processing
fdf62ed toaster: buildinfohelper Create target list for all types of build
36315fe toasterui: detect build run start correctly on Jethro

Two of these (020919b and fdf62ed) were on toaster-next, but had to be
removed; one (36315fe) was on Ed's branch, to fix Jethro build start
detection issues in the context of his work.

Unfortunately, these can't be removed cleanly by a rebase (I tried), so Ed
may have to do this to ensure nothing is broken in the process.

Elliot

On 4 April 2016 at 17:32, Michael Wood <michael.g.wood@intel.com> wrote:

> Yes, let's remove  "toaster: create Build object earlier in bitbake
> processing" from toaster-next. If it's not going up to bitbake-devel in
> it's current form and It's causing a regression there isn't any point
> keeping it around in toaster-next.
>
> Michael
>
> On 04/04/16 09:24, Smith, Elliot wrote:
>
>> We currently have this in toaster-next, but after discussion with RP,
>> we've agreed that this is probably not the right way to do this.
>>
>> RP suggested a couple of alternatives, which I can look into this week
>> (see bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=8440).
>>
>> For the moment, can I suggest that we remove this from toaster-next and
>> force push the branch?
>>
>> NOTE: I'm mentioning this because it will mess up everyone's Toaster
>> database, as the patch included a migration. You'll need to remove any
>> existing db and start again. It will also affect Ed's branch, as he rebased
>> on toaster-next with this patch in it.
>>
>> There is also a patch created by Michael which fixed an issue with my
>> patch, which I submitted to bitbake-devel last week. This failed to apply
>> because 7844358 wasn't accepted.
>>
>> So this patch should also be ignored for now:
>>
>> http://lists.openembedded.org/pipermail/bitbake-devel/2016-April/007258.html
>> I have already removed it from toaster-next.
>>
>> Details of the commit I plan to remove are below for reference.
>>
>> Elliot
>>
>>
>> commit 78443585bc92eca7140267126d53f749be3cdd6a
>> Author: Elliot Smith <elliot.smith@intel.com <mailto:
>> elliot.smith@intel.com>>
>> Date:   Thu Jan 28 16:21:01 2016 +0000
>>
>>     toaster: create Build object earlier in bitbake processing
>>     If a build fails because of a bitbake error occurring before the
>>     BuildStarted event fires, we do not generate a Build object
>>     for command-line builds. This means that failed command-line builds
>>     don't appear in Toaster at all.
>>     To resolve, split build creation into two steps:
>>     1. Just before buildTargets() is invoked on the XMLRPC server: create
>>     the base Build object. Note that as soon as a Toaster-triggered
>>     build starts, targets are added to it; but this event is the earliest
>>     point when task and targets are available for command-line builds.
>>     (This requires a new TargetsAcquired event to be fired by the XMLRPC
>>     server when the buildTargets() command is called.)
>>     2. BuildStarted event: add any layer information to either type of
>> build
>>     (command-line or Toaster-triggered).
>>     Note that the build_name property cannot be set until BuildStarted,
>>     as it is not available until then, which could cause problems
>>     for creating Build objects earlier; however, this property is
>>     redundant, as it's never used anywhere in Toaster, so it has been
>>     removed (along with any functions which refer to it).
>>     [YOCTO #8440]
>>     Signed-off-by: Elliot Smith <elliot.smith@intel.com <mailto:
>> elliot.smith@intel.com>>
>>     Signed-off-by: Michael Wood <michael.g.wood@intel.com <mailto:
>> michael.g.wood@intel.com>>
>>
>>
>> --
>> Elliot Smith
>> Software Engineer
>> Intel Open Source Technology Centre
>>
>>
>>
> --
> _______________________________________________
> toaster mailing list
> toaster@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/toaster
>



-- 
Elliot Smith
Software Engineer
Intel Open Source Technology Centre

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2016-04-05 10:10 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-04-04  8:24 Removing 7844358 from toaster-next ("create Build object earlier in bitbake processing") Smith, Elliot
2016-04-04 16:32 ` Michael Wood
2016-04-05 10:10   ` Smith, Elliot

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.