[Toaster] Toaster Weekly Meeting Minutes 02/24/16

Smith, Elliot elliot.smith at intel.com
Wed Feb 24 11:40:54 PST 2016


Thanks Belen, a very succinct and useful write up.

Elliot

On 24 February 2016 at 17:16, Barros Pena, Belen <
belen.barros.pena at intel.com> wrote:

> Attendees: Mihail, Ed, Elliot, Sujith, Dave, Michael, David, Brian, Belén
>
> Updates:
>
> Ed: still working on 7880. He wants to bring up as open
>
> Elliot: Worked on 8440 (catching early builds), patches waiting for
> review.  Worked on 8842 (build performance data, patches waiting for
> review. Also a bit on 8443 (improving display of failed builds), which
> depends on 8440. Did a bit more on figuring out bitbake and writing a
> beginning guides to it, but nothing published just yet
>
> Sujith: submitted patch for review for 8422
>
> Dave: submitted patches for 9101 and 9111. Opened a bug about adding
> packages with dependencies (9156). He has a fix for it but not submitted
> yet. Has taken a couple of other bugs.
>
> Michael: reviewing patches and working on build cancellation feature from
> Sujith. Sent an RFC about it: general approach is right, but it is
> currently blocked by sqlite table locking issues. Time back offs do not
> seem to fix the problem. Brian suggests we need to find out which process
> is causing the lock.
>
> David: catching up on things. 8037 seems to be obsolete by now
>
> Brian: met with Michael Halstead about layer index. We¹ll be getting layer
> index bugs. He is trying to make it easy to push to github and run the
> Toaster Selenium tests with Travis in order to test branches under review
> and catch regressions.
>
> Mihail: doing release candidate QA. On the Selenium front, they are
> updating the tests. Hopefully by next week tests will run again properly.
> Good because it affects Brian¹s work on Travis. Updated the runner, so
> that you can do --run alltests. Changes from Aníbal Limón might supersede
> some of the existing test running code.
>
> Belén: opening image customisation bugs, assigning them to Dave, and
> submitting some small UI patches.
>
> Triage bugs:
>
> No triage this week: we had a couple of important opens to discuss. We
> need to add layer index bugs to our usual triage.
>
> AR's:
>
> Unassigned - Understand and fix/write-up layer sources¹ odd inheritance
> structure.
> Michael - Expend documentation on image customization
> Stephen - invite Aníbal to the Toaster call [new]
> Brian - set 1:1 with Elliot about layer index [new]
>
> Opens:
>
> Brian: layer index.
>
> We are taking the layer index on because Paul Eggleton no longer has time
> to maintain it. The Toaster team will need to fix its bugs. Elliot will be
> "gatekeeper": will check the layers submitted to make sure they are
> layers, and contact maintainers when layers disappear. Elliot and Brian
> will sync off line.
>
> We will also be triaging layer index bugs from now on.
>
> The API changes to bitbake will make the management of layer index
> unpleasant in the short term. The online version is not seeing trouble
> because it's not reparsing recipes currently, but if you do, you get tons
> of errors.
>
> Michael Halstead contacted Elliot, Michael and Ed to give them access to
> infrastructure for development of layer index, which can also be used for
> other Toaster things like Patchwork.
>
> Ed: 7880.
>
> What's the reason of having bitbake server running for Toaster? Brian
> thinks that if you have 2 projects in Toaster (dog and cow) you will have
> 3 build dirs: build_cli, build_dog and build_cow. For build_dog and
> build_cow you can use toaster ui. But for build_cli you need bitbake
> server running.
>
> Ed suggests user could specify toaster ui when they want toaster to grab
> the information for their cli builds. Another way would be to set some
> variable or configuration to make toaster ui the default ui instead of
> knotty. How is knotty the default ui? Maybe there is already a variable
> you can set. We can set the toaster setup script to do that, and it can be
> overridden by passing -u knotty when issuing the bitbake command from cli.
> Ed agrees this would be reasonable.
>
> Michael thinks a third option would be a wrapper script for command line
> builds to talk to toaster, instead of calling bitbake directly. Brian
> thinks Ed's suggestion about the variable to set the default UI is pretty
> much the same thing Michael is suggesting. Michael thinks with the wrapper
> script we would have more control over the environment, to make sure it's
> set up correctly for toaster.
>
> So Ed is correct: we don't need a bitbake memory resident server for each
> build directory. That will simplify a lot of things: we can run parallel
> builds easier, and it would be possible to run project builds from the cli
> if you wanted to. He will figure out if there is already a variable
> setting the default bitbake ui, and set it to toaster when toaster is
> started.
>
>
> --
> _______________________________________________
> toaster mailing list
> toaster at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/toaster
>



-- 
Elliot Smith
Software Engineer
Intel Open Source Technology Centre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/toaster/attachments/20160224/12c52aa4/attachment.html>


More information about the toaster mailing list