While testing I have also noticed something in the error message when no name= parameter is set in the URI, the candidates list includes SRCREV_default and SRCREV_default:pn-X even though no name was explicitly specified.looking at the code, self.name defaults to 'default' when no name= param exists (line 1353 of __init__.py) which is what causes this.
Is this intentional behavior or is the candidates list supposed to only include SRCREV:pn-X and SRCREV when no name= is set? Best regards, Sai Sneha On Wed, 10 Jun 2026 at 2:18 PM, Sai Sneha via lists.openembedded.org <[email protected]> wrote: > Hi Richard, > > I tested this locally. You are right that the error message is > already clear: > > "Please set a valid SRCREV for url..." > > However parsing halts for ALL recipes with: > > "ERROR: Parsing halted due to errors" > > Not just the offending recipe. Is that acceptable behavior or > does it need fixing? > > Best regards, > Sai Sneha > > > On Wed, 10 Jun 2026 at 12:03 PM, Richard Purdie < > [email protected]> wrote: > >> On Wed, 2026-06-10 at 11:47 +0530, Sai Sneha wrote: >> > >> > I tested BB_NO_NETWORK:layer-core = "1" and found that it does >> > not prevent the parse crash for the case where SRCREV is >> > completely missing. >> > >> > The crash happens in srcrev_internal_helper() which raises >> > FetchError before any network access is attempted — so >> > BB_NO_NETWORK never gets checked. The BB_NO_NETWORK flag would >> > only help for the case where SRCREV is set to a floating >> > branch/tag and latest_revision() is called, since _lsremote() >> > calls check_network_access() there. >> >> FetchError isn't a crash, the code is finding there is a problem and >> raising an exception. The exception should say what the issue is. >> >> Doesn't that mean that case is already covered and we don't need to do >> anything further? >> >> > So it seems like two separate fixes are needed: >> > >> > 1. For missing SRCREV — something needs to prevent the parse >> > crash in srcrev_internal_helper(). Would it be appropriate >> > to check BB_NO_NETWORK in srcrev_internal_helper() itself >> > before raising FetchError? >> >> I don't understand why we need to trap this, then handle it again >> later? >> >> Cheers, >> >> Richard >> > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#238421): https://lists.openembedded.org/g/openembedded-core/message/238421 Mute This Topic: https://lists.openembedded.org/mt/119719972/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
