From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Subject: bug#24703: Store references in 8-byte chunks in compiled code Date: Thu, 10 Nov 2016 09:01:12 +0100 Message-ID: <87shqzyd9z.fsf@gnu.org> References: <87r37gstf6.fsf_-_@netris.org> <87d1j0sl1l.fsf@netris.org> <87a8e4glot.fsf@gnu.org> <8f2024ad-13c1-d4b1-1541-c2a5bddcb403@etorok.net> <87h98bdvng.fsf@gnu.org> <87k2d6qqee.fsf@netris.org> <20161024194022.GA1772@jasmine> <87insh1oxz.fsf@gnu.org> <87a8de7s6q.fsf@inria.fr> <87oa1o75ga.fsf@gnu.org> <20161109231652.GA12060@jasmine> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:56468) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c4kJD-0006zl-PF for bug-guix@gnu.org; Thu, 10 Nov 2016 03:02:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c4kJ8-0003bD-8W for bug-guix@gnu.org; Thu, 10 Nov 2016 03:02:07 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:36207) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c4kJ8-0003b5-44 for bug-guix@gnu.org; Thu, 10 Nov 2016 03:02:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <20161109231652.GA12060@jasmine> (Leo Famulari's message of "Wed, 9 Nov 2016 18:16:52 -0500") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Leo Famulari Cc: 24703@debbugs.gnu.org Leo Famulari skribis: > On Wed, Nov 09, 2016 at 09:40:05PM +0100, Ludovic Court=C3=A8s wrote: [...] >> The long-term goal is to rebuild everything with a compiler that has >> this patch, in the next =E2=80=98core-updates=E2=80=99. We might as wel= l switch to GCC >> 5 as the default compiler. >>=20 >> In the meantime, the only approach I can think of is to (1) ungraft more >> frequently than we=E2=80=99ve done so far, and (2) when we ungraft a pac= kage, >> add gcc@5 as an input such that it gets rebuilt without the problem. >>=20 >> Thoughts? > > Sounds good to me. I wonder, with our current build farm, how often can > we do the full rebuilds required by ungrafting? I don't yet have a sense > of how long it takes. I don=E2=80=99t know exactly. I have a feeling that the build farm has been underused over the last couple of weeks for instance, but no precise stats. I=E2=80=99d like to be able to gather usage stats so we can see whe= n the right time for rebuilds comes. For now I think we=E2=80=99ll merge core-updates Real Soon, and then start a staging branch or the python-updates one. Ludo=E2=80=99.