From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?B?VG9tw6HFoSDEjGVjaA==?= Subject: Re: reproducible builds and debugging information Date: Thu, 26 Mar 2015 22:51:15 +0100 Message-ID: <20150326215115.GF19723@venom.suse.cz> References: <20150322172632.GB3826@venom> <87zj72xftt.fsf@gnu.org> <20150325003352.GA5247@venom> <87pp7vqwtc.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sDKAb4OeUBrWWL6P" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49317) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YbFgQ-00077C-8H for guix-devel@gnu.org; Thu, 26 Mar 2015 17:51:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YbFgL-0008F3-7v for guix-devel@gnu.org; Thu, 26 Mar 2015 17:51:22 -0400 Received: from cantor2.suse.de ([195.135.220.15]:42347 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YbFgK-0008Ej-UF for guix-devel@gnu.org; Thu, 26 Mar 2015 17:51:17 -0400 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 0479FAC7F for ; Thu, 26 Mar 2015 21:51:15 +0000 (UTC) Content-Disposition: inline In-Reply-To: <87pp7vqwtc.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: guix-devel@gnu.org --sDKAb4OeUBrWWL6P Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 26, 2015 at 10:21:35PM +0100, Ludovic Court=C3=A8s wrote: >Tom=C3=A1=C5=A1 =C4=8Cech skribis: > >> On Tue, Mar 24, 2015 at 10:09:50PM +0100, Ludovic Court=C3=A8s wrote: > >[...] > >>>Packages that have an autoconf-based build system, and I suppose most >>>others, are built with -g. >> >> I can't confirm this statement. >> >> I added "debug" output to curl package: > >Indeed, I just checked and cURL overrides the default behavior. Here it >has to be configured with --enable-debug, which also enables the test >suite (!). Do you want to try that, and add the =E2=80=9Cdebug=E2=80=9D o= utput? > >>>The binaries get stripped by default and >>>debugging info is lost unless the package has a =E2=80=9Cdebug=E2=80=9D = output. >> >> OK, the difference -g and -ggdb is slight, but there is the problem >> with "debug" output. >> >> When package has output "debug" always - there is no problem. >> >> When package doesn't have "debug" output and I need it, mere adding >> output "debug" into package receipt will change the hash so I'll get >> different package. > >Right. > >>>Currently a few key packages have that, but most don=E2=80=99t (I think = Debian >>>does something similar, not sure about other distros.) >> >> On openSUSE you have available all the subpackage providing stripped >> debug informations and subpackage providing source code from the >> moment of build (so DWARF information in debug part can match the source= ). > >You mean there=E2=80=99s a =E2=80=98-debug=E2=80=99 package for every sing= le package? For every single binary package, yes. You can suppress it too. Why it is so surprising? >>>We could make it opt-out rather than opt-in, but the issue is disk usage >>>on build machine (including end-user machines.) See >>>. >>> >>>Thoughts? >> >> If we have distribution of reproducible packages, we can keep it >> opt-in and generate debug information next time (by not dropping >> it). > >That=E2=80=99s not how it works; generating the debug info requires redoin= g the >whole build process, but with a slight difference. I know, I was ambiguous again. We both meant the same. I would like to move the decision whether to keep or to drop debug information outside of the build itself to keep the hash the same. Imagine situation where you added "debug" output to every package and after each build the newly generated store with debug information is deleted (carefully, not to corrupt database, of course). Your hash still will be the same. Then someone reports bug, delivers coredump from some crash. You need debug info for analysis - you prevent from automatic deletion of the store with debug information. S_W --sDKAb4OeUBrWWL6P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUUf1AACgkQ37XrCapiVCNjOACfRqBLhyYzXAlRAl/aaoB45Af0 aWYAmwQ3CVY2+evduTOmfvfGXuy/WL8U =D1RN -----END PGP SIGNATURE----- --sDKAb4OeUBrWWL6P--