From: "Mark Hatle" <mark.hatle@kernel.crashing.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, 1 Sep 2021 14:55:11 -0500 [thread overview]
Message-ID: <4d731952-4626-2285-3ca2-a16ad24c2446@kernel.crashing.org> (raw)
In-Reply-To: <20210901194456.2642587-1-vishal.patel@xilinx.com>
On 9/1/21 2:44 PM, 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.
What we're attempting to do is specify both a network and local disk premirror
location. The network one seems to get added in the list first (for whatever
reason), but it never falls back to the disk version.
As the patch shows:
PREMIRROR = "http://.*/.* http://downloads.yoctoproject.org/releases/bitbake \n
http://.*/.* file://%s/test-file.tar.gz \n"
appears to fail when it gets to the first one, and never tries the second entry.
> Vishal Patel (1):
> tests/fetch.py: Add test case to verify PREMIRROR with mix of remote
> and local
>
> lib/bb/tests/fetch.py | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> --
> 2.25.1
>
> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
BTW we apologize for the footer, it shouldn't have been on this and the
associate patch email. We're working to get this removed in future conversations.
next prev parent reply other threads:[~2021-09-01 19:55 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 ` Mark Hatle [this message]
2021-09-01 21:40 ` [bitbake-devel] [PATCH 0/1] RFC Bug in PREMIRROR Richard Purdie
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=4d731952-4626-2285-3ca2-a16ad24c2446@kernel.crashing.org \
--to=mark.hatle@kernel.crashing.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).