Thanks Belen, a very succinct and useful write up. Elliot
On 24 February 2016 at 17:16, Barros Pena, Belen < [email protected]> 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 > [email protected] > https://lists.yoctoproject.org/listinfo/toaster > -- Elliot Smith Software Engineer Intel Open Source Technology Centre
-- _______________________________________________ toaster mailing list [email protected] https://lists.yoctoproject.org/listinfo/toaster
