From: Denys Dmytriyenko <denis@denix.org>
To: openembedded-devel@lists.openembedded.org
Subject: Re: RFC: Add http_proxy and ftp_proxy to BitBake white list
Date: Thu, 13 Nov 2008 02:28:47 -0500 [thread overview]
Message-ID: <20081113072847.GA9523@denix.org> (raw)
In-Reply-To: <20081112184416.GA6234@denix.org>
On Wed, Nov 12, 2008 at 01:44:16PM -0500, Denys Dmytriyenko wrote:
> On Sun, Nov 09, 2008 at 01:22:14PM +0000, Richard Purdie wrote:
> > For various reasons I've now had some experience of using bitbake behind
> > some pretty strict proxy setups. The problem is that its not as simple
> > as just setting http_proxy since some addresses need to go through the
> > proxy but things like a local source mirror might be on an internal
> > network and therefore shouldn't go through the proxy.
>
> Why not use the standard $no_proxy environment variable to list addresses
> inside the firewall?
>
> > I hence reworked things so you set HTTP_PROXY but can also set
> > HTTP_PROXY_IGNORE which is a list of base urls which should not use the
> > proxy. The fetcher code will only set http_proxy to HTTP_PROXY if the
> > url is not in the ignore list.
> >
> > FTP_PROXY and ftp_proxy works in a similar way.
>
> Looks redundant, as it can be achieved like this:
>
> $ export http_proxy=proxy.company.com:80
> $ export no_proxy=company.com,interweb.net
>
> > > So, is the idea the user has to set HTTP_PROXY in a conf file for wget
> > > proxy to work? What are the downsides to using http_proxy from the
> > > environment? At any rate, it seems like we have some inconsistencies
> > > in the various fetcher methods.
> >
> > The idea is the user sets HTTP_PROXY and optionally HTTP_PROXY_IGNORE to
> > make http proxying work. I'm planning to make bitbake ignore http_proxy
> > from the environment due to the problems is causes with mirror servers
> > behind the proxy.
> >
> > Hopefully this clears up the intent of the patches, the improvements are
> > based on real world usage problems.
>
> Even though I'd prefer it to be fixed properly with 15-year-old http_proxy and
> no_proxy environment variables, it does not matter too much, as long as any
> kind of http/ftp proxy support is merged into upstream BitBake, please. :)
> Thanks.
And speaking of proxies - since recently you removed GIT_PROXY_COMMAND from
the list of exported variables, what's the correct method of using Git behind
the proxy with BitBake?
--
Denys
next prev parent reply other threads:[~2008-11-13 7:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-23 23:09 RFC: Add http_proxy and ftp_proxy to BitBake white list Denys Dmytriyenko
2008-10-24 13:38 ` Cliff Brake
2008-10-24 15:17 ` Richard Purdie
2008-11-07 19:57 ` Cliff Brake
2008-11-07 20:24 ` Cliff Brake
2008-11-09 13:22 ` Richard Purdie
2008-11-12 18:44 ` Denys Dmytriyenko
2008-11-13 7:28 ` Denys Dmytriyenko [this message]
2008-11-13 15:32 ` Cliff Brake
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=20081113072847.GA9523@denix.org \
--to=denis@denix.org \
--cc=openembedded-devel@lists.openembedded.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.