On Fri, Jan 24, 2025 at 08:01:03PM +0530, Chirag Shilwant wrote:
> Hi Denys,
>
> On 24/01/25 04:05, Denys Dmytriyenko wrote:
> >> >+do_configure[network] = "1" > >+ > >+do_configure: prepend() {
> >> >+ if [ -n "${http_proxy}" ]; then > >+ export
> >HTTP_PROXY=${http_proxy} > >+ export http_proxy=${http_proxy} > >+
> >fi > >+ >
> >ZjQcmQRYFpfptBannerStart
> >This message was sent from outside of Texas Instruments.
> >Do not click links or open attachments unless you recognize the
> >source of this email and know the content is safe.
> >Report Suspicious
> ><https://us-phishalarm-ewt.proofpoint.com/EWT/v1/G3vK!uPdqXRfP1m07amYkfLMjnW_0WPoGAUc_xiEhDJ8PA6NpT0xA8jTf-KB9808zSr3fgbwdqDV_S4_t$>
> >
> >ZjQcmQRYFpfptBannerEnd
> >> >+do_configure[network] = "1"
> >> >+
> >> >+do_configure:prepend() {
> >> >+ if [ -n "${http_proxy}" ]; then
> >> >+ export HTTP_PROXY=${http_proxy}
> >> >+ export http_proxy=${http_proxy}
> >> >+ fi
> >> >+
> >> >+ if [ -n "${https_proxy}" ]; then
> >> >+ export HTTPS_PROXY=${https_proxy}
> >> >+ export https_proxy=${https_proxy}
> >> >+ fi
> >> > > Are these checks needed? If it is unset then exporting
> >doesn't hurt,
> >> could replace all this with:
> >> > export http_proxy
> >> export https_proxy
> >> do_configure[network] = "1"
> >> > >+do_compile[network] = "1"
> >> >+
> >> >+do_compile:prepend() {
> >> >+ # Used to download cmake dependencies when behind a proxy
> >> >+ if [ -n "${http_proxy}" ]; then
> >> >+ export HTTP_PROXY=${http_proxy}
> >> >+ export http_proxy=${http_proxy}
> >> >+ fi
> >> >+
> >> >+ if [ -n "${https_proxy}" ]; then
> >> >+ export HTTPS_PROXY=${https_proxy}
> >> >+ export https_proxy=${https_proxy}
> >> >+ fi
> >> > Do you need network during compile? Seems to only be used in
> >configure.
> >
> >Both of the above will get you in trouble later on - these are considered a
> >very bad antisocial behavior and an almost sure way to strip off of any Yocto
> >Project Compatible status...
>
> I completely understand your concerns about following best practices
> in Yocto.
> I was aware that the Yocto documentation now recommends limiting
> network access
> to the do_fetch task. However, I'd like to point out that many
> official Yocto Project
> layers still enable network access after do_fetch.
You are missing my point...
"Yocto Project Compatible" is not merely saying a layer works with the Yocto
Project.
It is a compliance and badging program that tests layers against a set of
defined criterias, recognizing those that pass as "Yocto Project Compatible".
For example, meta-ti layers are Yocto Project Compatible since very early days
and we kept it that way - it's being checked nightly on the YP autobuilder.
On the other hand, meta-arago layers never had Yocto Project Compatible
designation.
Moreover, except meta-oe, none of the other layers you linked to are Yocto
Project Compatible!
The "YP Compatible" program was "on hiatus" for quite some time, but is being
revamped now to re-launch some time in the near future - the Yocto Project
Technical Steering Committee has worked hard on the changes and I've been
closely involved - check the Technical Leadership tab here:
https://www.yoctoproject.org/about/leadership/
A wider range and more stricter criterias coming with this revamp are a direct
result of misbehaving layers and all the pain they cause to the community.
For example, most of the QA checks are becoming mandatory:
https://git.openembedded.org/openembedded-core/commit/?id=ce2e42ace2d15fb6745437cf0a7f07d28398ca12
We'll be catching layers that try to skip those QA checks with INSANE_SKIP:
https://git.openembedded.org/openembedded-core/commit/?id=9c3ba88628853b20fb4c98c99cf3fe8349024016
And catching layers that use network outside of do_fetch() is in the works:
https://git.yoctoproject.org/poky-contrib/tree/meta/classes-global/yocto-check-layer.bbclass?h=ross/checknetwork
All the corresponding documentation will be updated in due time...
You can find a rather short list of the past Yocto Project Compatible layers
that were recognzied and designated under the old program (new applications
are currently closed until the revamped program is out):
https://www.yoctoproject.org/development/yocto-project-compatible-layers/
For comparison, here's a much longer (but still not exhaustive) list of
registered YP layers - note how few of them have a little "YP Compatible"
badge next to their names:
https://layers.openembedded.org/layerindex/branch/master/layers/
And last week I also talked here on this list about efforts led by Ryan to
improve meta-arago layers quality to potentially seek YP Compatible status
some time in the future:
https://lists.yoctoproject.org/g/meta-arago/message/15738
That's why in my reply to you I pointed out problematic areas and suggested
looking for better alternatives early on, before those become bigger issues:
> >I'd suggest spending some time trying to find a way to do any and all
> >downloads inside the do_fetch() task, which is the only one allowed to have
> >network access.
> >
> >In other words - do_configure() and do_compile() are definitely not the right
> >places to do any network fetching...
But you are free to dismiss my recommendations...
--
Denys
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#15781):
https://lists.yoctoproject.org/g/meta-arago/message/15781
Mute This Topic: https://lists.yoctoproject.org/mt/110775616/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/meta-arago/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
