From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41534) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bXP9h-0004AS-Pd for qemu-devel@nongnu.org; Wed, 10 Aug 2016 04:46:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bXP9d-0003Pp-Kh for qemu-devel@nongnu.org; Wed, 10 Aug 2016 04:46:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44894) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bXP9d-0003Pi-Cv for qemu-devel@nongnu.org; Wed, 10 Aug 2016 04:46:25 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AD0E361E4C for ; Wed, 10 Aug 2016 08:46:24 +0000 (UTC) Date: Wed, 10 Aug 2016 16:39:21 +0800 From: Fam Zheng Message-ID: <20160810083921.GD19064@al.usersys.redhat.com> References: <1470756748-18933-1-git-send-email-berrange@redhat.com> <20160809170333.131781.95394@ex-std-node742.prod.rhcloud.com> <20160809171151.GO1530@redhat.com> <20160810014140.GD11351@al.usersys.redhat.com> <20160810080634.GC13393@redhat.com> <20160810081310.GB19064@al.usersys.redhat.com> <20160810082445.GD13393@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160810082445.GD13393@redhat.com> Subject: Re: [Qemu-devel] [PATCH for-2.8 v1 00/60] Modular build of trace event files List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: qemu-devel@nongnu.org, stefanha@redhat.com On Wed, 08/10 09:24, Daniel P. Berrange wrote: > On Wed, Aug 10, 2016 at 04:13:10PM +0800, Fam Zheng wrote: > > On Wed, 08/10 09:06, Daniel P. Berrange wrote: > > > On Wed, Aug 10, 2016 at 09:41:40AM +0800, Fam Zheng wrote: > > > > On Tue, 08/09 18:11, Daniel P. Berrange wrote: > > > > > > > > > > Can we get this report to include details of the > > > > > > > > > > a) the software versions of gcc, binutils, and any -devel packages > > > > > we're building against > > > > > > > > > > b) the exact arguments + env variables used to invoke configure, > > > > > not merely its output > > > > > > > > > > so we don't have to go digging into the docker test systemm to > > > > > try and reverse engineer this info > > > > > > > > The whole point of docker test system is offer a relatively easy reproducer to > > > > developers, so I'm reluctant to engineer patchew or the test script it runs for > > > > that. > > > > > > That's just pointlessly creating extra work for the developers reading > > > these build reports. If you outputted the info I suggest, it can help > > > developers diagnose the problems more quickly. Even if running the > > > docker env locally is possible & even easy, it doesn't make it faster > > > than reading the relevant info from email report in front of you. > > > > I agree with your point, I just don't know how to do a) neatly, except for a > > vast change to configure. > > Why do you need todo it in configure ? I was thinking your docker receipe > that invokes configure could just do it - not least because the commands to > run to get the data will be different based on which distro you're running > in the docker image in question. Then the script needs to be updated to work with different package management systems (rpm and deb). For now they only call standard Linux commands. That's least of the problem, though. The more tricky question is how the script can tell which packages are relevant (or, used). I assume the number of packages in a docker image is quite limited (fedora has 396, ubuntu 574), but dumping the whole list is still noisy nevertheless. Also, depending on the configure option, a submodule can be used instead, or a local built library. Not that we have a lot of these now, but it's a factor of complication. On the other hand, configure knows when to use pkg-config --modversion, or git describe, or something else, depending on how and where it discovers the compiler and -devel libs etc.. Fam