From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55509) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gELVc-0007fX-I3 for guix-patches@gnu.org; Sun, 21 Oct 2018 17:43:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gELHS-0007hw-3M for guix-patches@gnu.org; Sun, 21 Oct 2018 17:29:02 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:58712) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gELHR-0007hs-VA for guix-patches@gnu.org; Sun, 21 Oct 2018 17:29:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gELHR-00055c-QP for guix-patches@gnu.org; Sun, 21 Oct 2018 17:29:01 -0400 Subject: [bug#33038] [PATCH 3/6] bootstrap: Add %bootstrap-mes. Resent-Message-ID: From: Jan Nieuwenhuizen References: <20181014085857.3863-1-janneke@gnu.org> <20181014085857.3863-3-janneke@gnu.org> <87r2gld3nt.fsf@gnu.org> <875zxxax4f.fsf@gnu.org> <87sh0z8294.fsf@fastmail.com> <877eib8119.fsf@gnu.org> Date: Sun, 21 Oct 2018 23:28:40 +0200 In-Reply-To: <877eib8119.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Sun, 21 Oct 2018 23:04:02 +0200") Message-ID: <87k1mb9egn.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 33038@debbugs.gnu.org Ludovic Court=C3=A8s writes: > Marius Bakke skribis: > >> Jan Nieuwenhuizen writes: >> >>>> It would be nice to maybe make this a separate commit (following the >>>> make-bootstrap.scm changes) so that you can state in the commit log >>>> which commit was used to build this binary. >>> >>> Ah yes, that's nice. Hmm, there's a slight complication because for the >>> i686-linux version I cheated; icu4c, python-more-itertools and swig fail >>> to build on core-updates-next. I added a hack and reverted that... >>> which is probably less than great. So I cleaned it up a bit and just >>> added it. >> >> FYI the issues mentioned here have been fixed in the 'core-updates' >> branch. I suppose you can still rebase on it, or just merge it. > > Merging core-updates into core-updates-next sounds like a good idea. > > Thanks for letting us know, Marius! Great, merged and rebased core-updates-next on my gitlab. More admin work todo, but that's alright. janneke