From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.181]) by mx.groups.io with SMTP id smtpd.web10.3694.1596227802565958681 for ; Fri, 31 Jul 2020 13:36:43 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@linaro.org header.s=google header.b=oO99l3Bd; spf=pass (domain: linaro.org, ip: 209.85.219.181, mailfrom: nicolas.dechesne@linaro.org) Received: by mail-yb1-f181.google.com with SMTP id p191so647141ybg.0 for ; Fri, 31 Jul 2020 13:36:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B9Gxfifh2y+Kj73pD8m6pkTAnhRNxGmFd+7V2Pb/1qk=; b=oO99l3Bd86DQPaeJrBMjB7uqNbyuaEyxBWnQpZ9pDsdNqQhH7ELnwkgT3Oe91zzaUr UwyDHSZjQPbCwLn79DomETRxPLbNtoWS1h+fY6WGhFTaCp49OtyeaPu5+VGaf4CzvWA7 Q1QCMB1DaFlOGiDHNC+58oT3gM/5hZ26rdnFGPXq+W/Qhz3tFWzRhDLVYArcVOvB2PZZ hCwKpHKR0YnSSokSPg0bg+NFKe/NtbiQNZQxs0rSUCF70lQsH85t+5x/b50ujVvUz3vL pxrftH8mo8n3r7pV44usROFAaUko5m1nuGzyWmX2zvfo6JkNydQ8a54Z+gdVbEzKTuCM XosQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=B9Gxfifh2y+Kj73pD8m6pkTAnhRNxGmFd+7V2Pb/1qk=; b=LBjxKf3ImQf/YOEBZNHyMT2KfqsRmzCFGjSTq0f8JvCFrNZhyAUvCePRxXCWaZlrEL V57BlzRrJjfC3LTJNGev1DB4ffJHoihRkvEx846Juk2v8Qw05VvtGuJmP5EjkwC5wqpc zHyVCc1JCKdcrnYInAYWeNjnoZaHxUSVqahWqgkQ6+YQ4aPFTMeKQ5HdKECkif7lgvSU BykI8qbUfzMb/sdQ1fYM5GVc7ETQePoNs2XyY8+SB7aWHEgPk2t9l9H7RK866eoyzE7g hmh8BSwbAVRUjoWQCv7jI8qhxfks7BhtfLZw+FbgHuhPfHDIvovEB6kiZHCiCqnCzkfe NmGg== X-Gm-Message-State: AOAM5304jdoQkbipa+lk0T3xPtFwD/PNcg5DMFwZyTFt2PwslDoJy4K+ 5bVxEotuunrMRCyw/rbyOCajG9Wrk9xtLOlbZMZ6gQ== X-Google-Smtp-Source: ABdhPJxOTMeNyksfYfTwbjKJ9Q9rO8EXMekPIbhcHhJn8Mt2BKMTfnLEghkNopze1exxw3RmB/kFqM88lagTMt5hHPM= X-Received: by 2002:a25:32c8:: with SMTP id y191mr8961441yby.273.1596227801534; Fri, 31 Jul 2020 13:36:41 -0700 (PDT) MIME-Version: 1.0 References: <20200728224149.GA22506@linux-uys3> In-Reply-To: From: "Nicolas Dechesne" Date: Fri, 31 Jul 2020 22:36:30 +0200 Message-ID: Subject: Re: [docs] [yocto] Yocto Technical Team Minutes, Engineering Sync, for July 28 2020 To: "Morton, Mark" Cc: Trevor Woerner , "docs@lists.yoctoproject.org" Content-Type: multipart/alternative; boundary="000000000000176fdb05abc2bf0c" --000000000000176fdb05abc2bf0c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le ven. 31 juil. 2020 =C3=A0 22:06, Morton, Mark a =C3=A9crit : > > > > -----Original Message----- > > From: docs@lists.yoctoproject.org On > Behalf > > Of Nicolas Dechesne > > Sent: Wednesday, July 29, 2020 12:37 AM > > To: Trevor Woerner > > Cc: docs@lists.yoctoproject.org; Morton, Mark > > > > Subject: Re: [docs] [yocto] Yocto Technical Team Minutes, Engineering > Sync, > > for July 28 2020 > > > > On Wed, Jul 29, 2020 at 12:42 AM Trevor Woerner > > wrote: > > > > > > Yocto Technical Team Minutes, Engineering Sync, for July 28 2020 > > > archive: > > > > > https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7 > > QwKC5w > > > WVDg9dDH4/edit > > > > > > =3D=3D disclaimer =3D=3D > > > 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. > > > > > > =3D=3D attendees =3D=3D > > > Trevor Woerner, Stephen Jolly, Armin Kuster, Josef Holzmayr, Richard > > > Purdie, Trevor Gamblin, Joshua Watt, Mark Morton, Ross Burton, Bruce > > > Ashfield, Steve Sakoman, (phone-in ??), Jon Mason, Randy MacLeod, > > > Scott Murray, Denys Dmytriyenko > > > > > > =3D=3D notes =3D=3D > > > - fixed a race on AB wrt perl > > > - 3.1.2 into QA > > > - 3.2-m2 to QA once they=E2=80=99re done with 3.1.2 > > > > > > =3D=3D general =3D=3D > > > RP: load of perl issues over the weekend, believe to have found issue > > > RP: lots of qemumips issues, not sure why, perhaps a timeouts issue? > (no > > ping > > > within 30 seconds) > > > RP: some infrastructure issues (one worker has become corrupted) > > > > > > RP: curious to know what people think about 3.1.2: there is a bitbake > issue > > > with toaster, should we release then fix or wait for fix before > release? > > > SS: maybe we should get feedback from people using toaster > > > RP: the fix is simple, maybe release 3.1.2 (with release note) then > > > fix > > > > > > RP: merged re-arrangement of package manager code, this puts more of > > our code > > > into python libraries instead of bbclass files, which is the > direction i > > > want to take going forward > > > RP: i need to start a conversation on oe-architecture for future > > > directions > > > RP: e.g. binary package feeds, we want to capture these use-cases int= o > the > > > wiki > > > > > > [NB: done! see https://wiki.yoctoproject.org/wiki/Future_Directions] > > > > > > RP: we also posted the current agreement on =E2=80=9Cinclusive langua= ge=E2=80=9D as > agreed > > > on by various groups (oe board, oe-tsc, yp-tsc) > > > > > > TW: what=E2=80=99s the thinking behind moving code to libraries vs bb= class? > > > RP: pro: parsing speed con: variable dependency tracking is lost > > > RP: lots of python code gets written to logs etc, which slows it down > > > JPEW: does bitbake automatically detect variable dependencies in > library > > code? > > > RP: no. maybe we just need to do the scan once? > > > TW: do we lose flexibility? (e.g. it=E2=80=99s easy to copy+paste+mod= ify a > bbclass, > > > will that be possible?) > > > RP: there will still be all the same entry points, so it should be > > > possible > > > RP: i=E2=80=99m worried about the size of the datastore in memory and= it is a > > > bottleneck > > > > > > RP: i wonder why qemumips is so slow? > > > Randy: i think Cisco are the only ones caring about mips > > > RP: yes, and Comcast too i think > > > > > > MM: have been wrapped up in $WORK stuff, but will be working on docs > > > conversion soon > > > RP: MH has been putting infrastructure in place and Nico is looking > forward > > to > > > getting this going > > > MM: do we want to try to reproduce our current colours/formatting or > try > > > something new > > > RP: i like what we have, the project does have an existing scheme, bu= t > we > > can > > > change if something else makes sense > > > > I have some updates on Sphinx.. > > I recall that the work in progress can be found here: > > https://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/log/?h=3Dsphinx > > > > The automated conversion from DocBook to Sphinx is managing 'internal' > > links quite badly, so it results in a significant amount of work to > fixup links. Also > > since I wanted to use the Sphinx builtin 'glossary' > > for terms and variables in the reference manual, that also required me = to > > update how links work for terms and variables. That's why it's taking > more > > time than I would like. I manage to use some automation/regexp, and do = a > bit > > of manual fix up as well. > > > > I also started to experiment with customization in the CSS theme, to > change > > some color/formatting. It's not done yet, but it has got > > better: > > https://people.linaro.org/~nicolas.dechesne/yp-docs/html/ref-manual/ref= - > > manual.html > > I see you got rid of some of the more obvius "funny colors" - the Notes > look much better, for example. > I cloned the new sphinx branch and started looking at the implementation > some. To make these changes, are you updating the > repoDir/documentation/sphinx-static/theme_overrides.css file, or is there > somewhere else you're making the changes? Yes. All CSS customization is done in this file. It overrides the css coming from the base theme template that we use. Thanks for your help! I definitely need some help! > > Thanks, > -Mark M > > > > > For now we generate a single large documentation 'website' that include= s > all > > existing docs, instead of publishing each document separately. I think > it's an > > important change compared to how our documentation was published so far= . > I > > personally like that quite a bit, and think it's 'better' this way, but > I would really > > want to hear from you and that we agree this is what we want for the > project. > > We still need to look at how we want to generate PDF/offline > documentation > > though. And we need to decide how to manage the bitbake manual which si= ts > > in the bitbake git tree, so right now it's published separately. > > > > Side note: the VSCode extension for reST is quite good > > (https://docs.restructuredtext.net/index.html) > > > > > > > > TW: i do lots of builds, never seen issues, why are there so many > failures on > > > AB? > > > RP: do you do oe-selftest or testsdk builds? > > > TW: no > > > RP: do you do mips builds? > > > TW: no > > > RP: so these are the areas where we see these failures, =E2=80=9Cregu= lar=E2=80=9D > builds > > > are okay > > > SS: i don=E2=80=99t see issues on my builds but that=E2=80=99s probab= ly because of > working > > > these issues out on the AB > > > RP: infrastructure issues are low, it=E2=80=99s mostly race issues th= at come > out of > > > the extreme load of the AB or intermittent architecture issues > that are > > > rarely tested > > > > --000000000000176fdb05abc2bf0c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Le=C2=A0ven. 31 juil. 2020 =C3=A0 22:06, Morton, Mark <<= a href=3D"mailto:Mark.Morton@windriver.com">Mark.Morton@windriver.com&g= t; a =C3=A9crit=C2=A0:


> -----Original Message-----
> From: docs@lists.yoctoproject.org <docs@lists.yoctoproject.org> On Behalf > Of Nicolas Dechesne
> Sent: Wednesday, July 29, 2020 12:37 AM
> To: Trevor Woerner <twoerner@gmail.com>
> Cc: d= ocs@lists.yoctoproject.org; Morton, Mark
> <Mar= k.Morton@windriver.com>
> Subject: Re: [docs] [yocto] Yocto Technical Team Minutes, Engineering = Sync,
> for July 28 2020
>
> On Wed, Jul 29, 2020 at 12:42 AM Trevor Woerner <twoerner@gmail.com>
> wrote:
> >
> > Yocto Technical Team Minutes, Engineering Sync, for July 28 2020<= br> > > archive:
> >
> https://docs.google.com/documen= t/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7
> QwKC5w
> > WVDg9dDH4/edit
> >
> > =3D=3D disclaimer =3D=3D
> > Best efforts are made to ensure the below is accurate and valid.<= br> > > However, errors sometimes happen. If any errors or omissions are<= br> > > found, please feel free to reply to this email with any correctio= ns.
> >
> > =3D=3D attendees =3D=3D
> > Trevor Woerner, Stephen Jolly, Armin Kuster, Josef Holzmayr, Rich= ard
> > Purdie, Trevor Gamblin, Joshua Watt, Mark Morton, Ross Burton, Br= uce
> > Ashfield, Steve Sakoman, (phone-in ??), Jon Mason, Randy MacLeod,=
> > Scott Murray, Denys Dmytriyenko
> >
> > =3D=3D notes =3D=3D
> > - fixed a race on AB wrt perl
> > - 3.1.2 into QA
> > - 3.2-m2 to QA once they=E2=80=99re done with 3.1.2
> >
> > =3D=3D general =3D=3D
> > RP: load of perl issues over the weekend, believe to have found i= ssue
> > RP: lots of qemumips issues, not sure why, perhaps a timeouts iss= ue? (no
> ping
> >=C2=A0 =C2=A0 =C2=A0within 30 seconds)
> > RP: some infrastructure issues (one worker has become corrupted)<= br> > >
> > RP: curious to know what people think about 3.1.2: there is a bit= bake issue
> >=C2=A0 =C2=A0 =C2=A0with toaster, should we release then fix or wa= it for fix before release?
> > SS: maybe we should get feedback from people using toaster
> > RP: the fix is simple, maybe release 3.1.2 (with release note) th= en
> > fix
> >
> > RP: merged re-arrangement of package manager code, this puts more= of
> our code
> >=C2=A0 =C2=A0 =C2=A0into python libraries instead of bbclass files= , which is the direction i
> >=C2=A0 =C2=A0 =C2=A0want to take going forward
> > RP: i need to start a conversation on oe-architecture for future<= br> > > directions
> > RP: e.g. binary package feeds, we want to capture these use-cases= into the
> >=C2=A0 =C2=A0 =C2=A0wiki
> >
> > [NB: done! see https://wiki.yoctoproje= ct.org/wiki/Future_Directions]
> >
> > RP: we also posted the current agreement on =E2=80=9Cinclusive la= nguage=E2=80=9D as agreed
> >=C2=A0 =C2=A0 =C2=A0on by various groups (oe board, oe-tsc, yp-tsc= )
> >
> > TW: what=E2=80=99s the thinking behind moving code to libraries v= s bbclass?
> > RP: pro: parsing speed con: variable dependency tracking is lost<= br> > > RP: lots of python code gets written to logs etc, which slows it = down
> > JPEW: does bitbake automatically detect variable dependencies in = library
> code?
> > RP: no. maybe we just need to do the scan once?
> > TW: do we lose flexibility? (e.g. it=E2=80=99s easy to copy+paste= +modify a bbclass,
> >=C2=A0 =C2=A0 =C2=A0will that be possible?)
> > RP: there will still be all the same entry points, so it should b= e
> > possible
> > RP: i=E2=80=99m worried about the size of the datastore in memory= and it is a
> >=C2=A0 =C2=A0 =C2=A0bottleneck
> >
> > RP: i wonder why qemumips is so slow?
> > Randy: i think Cisco are the only ones caring about mips
> > RP: yes, and Comcast too i think
> >
> > MM: have been wrapped up in $WORK stuff, but will be working on d= ocs
> >=C2=A0 =C2=A0 =C2=A0conversion soon
> > RP: MH has been putting infrastructure in place and Nico is looki= ng forward
> to
> >=C2=A0 =C2=A0 =C2=A0getting this going
> > MM: do we want to try to reproduce our current colours/formatting= or try
> >=C2=A0 =C2=A0 =C2=A0something new
> > RP: i like what we have, the project does have an existing scheme= , but we
> can
> >=C2=A0 =C2=A0 =C2=A0change if something else makes sense
>
> I have some updates on Sphinx..
> I recall that the work in progress can be found here:
> https://git.yoctoproject.o= rg/cgit/cgit.cgi/yocto-docs/log/?h=3Dsphinx
>
> The automated conversion from DocBook to Sphinx is managing 'inter= nal'
> links quite badly, so it results in a significant amount of work to fi= xup links. Also
> since I wanted to use the Sphinx builtin 'glossary'
> for terms and variables in the reference manual, that also required me= to
> update how links work for terms and variables. That's why it's= taking more
> time than I would like. I manage to use some automation/regexp, and do= a bit
> of manual fix up as well.
>
> I also started to experiment with customization in the CSS theme, to c= hange
> some color/formatting. It's not done yet, but it has got
> better:
> https://people.linaro.o= rg/~nicolas.dechesne/yp-docs/html/ref-manual/ref-
> manual.html

I see you got rid of some of the more obvius "funny colors" - the= Notes look much better, for example.
I cloned the new sphinx branch and started looking at the implementation so= me. To make these changes, are you updating the repoDir/documentation/sphin= x-static/theme_overrides.css file, or is there somewhere else you're ma= king the changes?

Yes. All CSS customization is done in this file. It overrides the css comi= ng from the base theme template that we use.

Thanks for your help! I definitely need some help!



Thanks,
-Mark M

>
> For now we generate a single large documentation 'website' tha= t includes all
> existing docs, instead of publishing each document separately. I think= it's an
> important change compared to how our documentation was published so fa= r. I
> personally like that quite a bit, and think it's 'better' = this way, but I would really
> want to hear from you and that we agree this is what we want for the p= roject.
> We still need to look at how we want to generate PDF/offline documenta= tion
> though. And we need to decide how to manage the bitbake manual which s= its
> in the bitbake git tree, so right now it's published separately. >
> Side note: the VSCode extension for reST is quite good
> (https://docs.restructuredtext.net/index.html)<= br> >
> >
> > TW: i do lots of builds, never seen issues, why are there so many= failures on
> >=C2=A0 =C2=A0 =C2=A0AB?
> > RP: do you do oe-selftest or testsdk builds?
> > TW: no
> > RP: do you do mips builds?
> > TW: no
> > RP: so these are the areas where we see these failures, =E2=80=9C= regular=E2=80=9D builds
> >=C2=A0 =C2=A0 =C2=A0are okay
> > SS: i don=E2=80=99t see issues on my builds but that=E2=80=99s pr= obably because of working
> >=C2=A0 =C2=A0 =C2=A0these issues out on the AB
> > RP: infrastructure issues are low, it=E2=80=99s mostly race issue= s that come out of
> >=C2=A0 =C2=A0 =C2=A0the extreme load of the AB or intermittent arc= hitecture issues that are
> >=C2=A0 =C2=A0 =C2=A0rarely tested
> >
--000000000000176fdb05abc2bf0c--