bitbake-devel.lists.openembedded.org archive mirror
 help / color / mirror / Atom feed
From: "Richard Purdie" <richard.purdie@linuxfoundation.org>
To: Vishal Patel <vishal.patel@xilinx.com>,
	 bitbake-devel@lists.openembedded.org
Cc: mark.hatle@xilinx.com
Subject: Re: [bitbake-devel] [PATCH 0/1] RFC Bug in PREMIRROR
Date: Wed, 01 Sep 2021 22:40:57 +0100	[thread overview]
Message-ID: <e648cf6d7d613e0ee1d5ad7b3ff0d8b0d332e6db.camel@linuxfoundation.org> (raw)
In-Reply-To: <20210901194456.2642587-1-vishal.patel@xilinx.com>

On Wed, 2021-09-01 at 12:44 -0700, Vishal Patel wrote:
> I think we found a bug in the PREMIRROR system where if both a remote and local
> PREMIRROR is defined, as well as BB_NO_NETWORK = '1', the system will fail with
> 
> bb.fetch2.NetworkAccess: Network access disabled through BB_NO_NETWORK (or set indirectly due to use of BB_FETCH_PREMIRRORONLY)
> 
> instead of trying the next PREMIRROR which is a local file:// based one.
> The attached patch only adds a test case for the issue, but does not fix the problem.
> If anyone can point me to where to fix the problem, I can work on this.

Thanks for the testcase, that does at least make this easy to see.

Running the test, it is clear from the trace that after trying a mirror, the
bb.fetch2.NetworkAccess exception is fatal and stops any other url from being
tried. That does seem not to be what the user would want.

I was going to let you debug that but I did quickly try this:


diff --git a/bitbake/lib/bb/fetch2/__init__.py
b/bitbake/lib/bb/fetch2/__init__.py
index 914fa5c0243..65d8c38af76 100644
--- a/bitbake/lib/bb/fetch2/__init__.py
+++ b/bitbake/lib/bb/fetch2/__init__.py
@@ -1034,7 +1034,7 @@ def try_mirror_url(fetch, origud, ud, ld, check = False):
         return ud.localpath
 
     except bb.fetch2.NetworkAccess:
-        raise
+        return False
 
     except IOError as e:
         if e.errno in [errno.ESTALE]:

and found that does make your test case pass. It also doesn't regress any other
test that I spotted in quick testing.

I'm not sure if that is the correct fix, I'd need to think about it a bit more. 

The question is whether if you disable the networking, you want errors on
network access or want the accesses disabled. Some people do want to know if the
network is used when disabled and BB_NO_NETWORK may mean different things to
different people.

Cheers,

Richard


  parent reply	other threads:[~2021-09-01 21:41 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-01 19:44 [PATCH 0/1] RFC Bug in PREMIRROR Vishal Patel
2021-09-01 19:44 ` [PATCH 1/1] tests/fetch.py: Add test case to verify PREMIRROR with mix of remote and local Vishal Patel
2021-09-01 19:55 ` [bitbake-devel] [PATCH 0/1] RFC Bug in PREMIRROR Mark Hatle
2021-09-01 21:40 ` Richard Purdie [this message]
2021-09-01 21:46   ` Mark Hatle
2021-09-01 21:48     ` Richard Purdie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e648cf6d7d613e0ee1d5ad7b3ff0d8b0d332e6db.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=bitbake-devel@lists.openembedded.org \
    --cc=mark.hatle@xilinx.com \
    --cc=vishal.patel@xilinx.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).