From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [OSSTEST PATCH] mg-debian-installer-update: produce
 deterministic output
Date: Wed, 4 Feb 2015 15:45:00 +0000
Message-ID: <1423064700.24924.21.camel@citrix.com>
References: <1420903137-21819-1-git-send-email-ian.campbell@citrix.com>
	<1420906214.11796.112.camel@citrix.com>
	<1420906656.11796.114.camel@citrix.com>
	<21683.48573.811674.951250@mariner.uk.xensource.com>
	<1421065852.26317.22.camel@citrix.com>
	<21714.15725.266212.255513@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <21714.15725.266212.255513@mariner.uk.xensource.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xen.org
List-Id: xen-devel@lists.xenproject.org

On Wed, 2015-02-04 at 15:40 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [OSSTEST PATCH] mg-debian-installer-update: produce deterministic output"):
> > On Mon, 2015-01-12 at 12:27 +0000, Ian Jackson wrote:
> > > Ian Campbell writes ("Re: [Xen-devel] [OSSTEST PATCH] mg-debian-installer-update: produce deterministic output"):
> > > > We might like to consider something along these lines for the future:
> > > 
> > > A reasonable idea (although I wonder if it should be configurable).
> > 
> > I did consider just inserting a $CURL_OPTS which could be set to include
> > pragma no-cache from the command line. I mostly didn't because I was too
> > lazy to think about the correct shell quoting at the time...
> 
> I have pushed this.  I edited a comment which talked about
> "transparent proxies" (why is a lie) to refer to "intercepting
> proxies" (which is not).
> 
> A "transparent proxy" is (as defined in the RFCs) one which refrains
> from making certain changes to requests explicitly proxied through it.
> 
> A proxy which operates without awareness on the client side by
> intercepting TCP streams at routers is an "intercepting proxy".

Ack.