On Tue, Jun 9, 2020 at 2:16 PM Trevor Woerner <[email protected]> wrote:
> Yocto Technical Team Minutes, Engineering Sync, for June 9 2020 > archive: > https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit > > == disclaimer == > Best efforts are made to ensure the below is accurate and valid. However, > errors sometimes happen. If any errors or omissions are found, please feel > free to reply to this email with any corrections. > > == attendees == > Trevor Woerner, Jan-Simon Möller, Stephen Jolly, Trevor Gamblin, Bruce > Ashfield, Scott Murray, Paul Barker, Michael Halstead, Jon Mason, Richard > Purdie, Joshua Watt, Armin Kuster, Tim Orling, Sathishkumar Duraisamy, > henriknj, Ross Burton, Jeremy Puhlman > > == notes == > - 2.7.4 released last week > - 3.1.1 built, but has issues, not sent to QA yet > - M1 early next week (to build) > - thanks to AlexK for lots of fixes > > == general == > RP: > problems with 3.1.1. qemu(-mips?) failed with taskhash mismatches, not > sure why > > > RP: > devtool, patchtest, patchwork, and wic looking for maintainers > PaulB: > patchtest/patchwork still on python2, needs 2→3 update. patchtest > should be moved to OE-core so it can be noticed by more people > > > RP: > lots of recipe upgrades, happy with where master is (wrt to recipe > versions), still need to update qemu to 5 > > > JPEW: > did RP see my patch to mc-depends to make it backwards compatible? > RP: > dismayed it was more complex than hoped, but looks okay > JPEW: > i’m using a proxy object otherwise we need to duplicate a lot of code > with a lot of if’s > RP: > saw the BBMASK thing for multiconfig that needed index checking, sad > that we’ll be stuck with that going forward (in command.py) mostly for > backwards compatibility (e.g. file checking). another option is to have > a new API and append a ‘2’ to the end so callers will call the right > things (old or new). the code’s probably going to get worse and worse > with every new parameter we want to add (in the future) > > JPEW: > re multiconfig, sometimes the old full “multiconfig” string > doesn’t work but the new “mc” string does, can we drop > “multiconfig”? changed in 2.7? or 3.0? there’s a bugzilla somewhere. > some code handles both, some doesn’t > RP: > we can get rid of it, despite the expected screaming > > > RP: > re devtool, reports on mailing list that devtool isn’t mc-compliant > RP: > we have a horrible hack for PRserver > RP: > highlights the need for a dedicated maintainer > > > PaulB: > re patchwork, kernel.org are using a newer version of patchwork that > is > python3-compatible, is maintained, but missing some things we need > Timo: > i looked at freedesktop.org’s gitlab, they’ve made a lot of changes > from where we forked from them, they’re also using python3 and django2. > going with mainline will miss features that we’re used to > PaulB: > make a list of the gap items, then decide if we can live without these > things > Timo: > i looked at the fd.o’s patchwork and saw that many of the things we > added to our fork have been added (but differently) in fd.o’s. e.g. we > added a superseded feature, doesn’t seem to be on any other patchworks > PaulB: > would like to spin up concurrent patchworks to see how the react to the > mailing list > Timo: > good idea, maybe we can work together on that > PaulB: > for patchtest it seems obvious what steps are required, patchwork less > clear > Timo: > https://gitlab.freedesktop.org/patchwork-fdo > Timo: > might be a lot of work to compare ours with fd.o’s patch by patch to > see > PaulB: > we need to figure out if we can live with some upstream version, to cut > down on the effort of having our own fork > RP: > but it’ll cause a lot of pain if, for example, the superceded feature > is > missing > Timo: > we’re better off putting resources elsewhere. upstream looks hard, but > i think patchwork-fdo looks like it might work, maybe easier to submit > to > patchwork-fdo rather than upstream? > TrevorW: > maybe fdo would really like a superceded feature, they split from > upstream for same reasons as us, they probably share the same > frustrations > Timo: > agreed, we should reach out to them > RP: > we should get a list first before reaching out > Timo: > we probably have about 30 patches on top of upstream, although most of > them of them are probably just to add the supercede feature Captured notes and recent research/discovery in the bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13684 We have 49 commits since forking from patchwork-fdo. Upstream patchwork-fdo has 166 commits since we forked. > PaulB: > is there anything in bugzilla? 13684 is a django update > PaulB: > to take action to capture this discussion in bugzilla > Timo: > Amber working on layerindex, but maybe we can have her work on this too > (not a promise), she has a lot of django experience > > > Timo: > re perl dependency. there’s an existing oe-package-data util script, > i’m using almost exact same code in a bitbake task, should this be > refactored to lib/oe? > RP: > sounds good, but depends on the implementation, in general i’m in > favour > of strong APIs in lib/oe. e.g. “packagedata” is too generic. the > history was that packagedata.py was created as a way of pulling code > out > of a bbclass > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#49614): https://lists.yoctoproject.org/g/yocto/message/49614 Mute This Topic: https://lists.yoctoproject.org/mt/74784236/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
