From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?G=C3=A1bor?= Boskovits Subject: bug#29537: Core updates broken Date: Sun, 3 Dec 2017 20:04:27 +0100 Message-ID: References: <87vahnzyq9.fsf@fastmail.com> <87bmjf4r0k.fsf@elephly.net> <87fu8rzm83.fsf@fastmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="089e082658b0568399055f74452c" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:43712) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLZZZ-0001jM-Uz for bug-guix@gnu.org; Sun, 03 Dec 2017 14:05:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eLZZW-0005yG-PS for bug-guix@gnu.org; Sun, 03 Dec 2017 14:05:05 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:35092) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eLZZW-0005yC-LU for bug-guix@gnu.org; Sun, 03 Dec 2017 14:05:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eLZZW-0005oG-Dl for bug-guix@gnu.org; Sun, 03 Dec 2017 14:05:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87fu8rzm83.fsf@fastmail.com> 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: Marius Bakke Cc: 29537@debbugs.gnu.org --089e082658b0568399055f74452c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'd go the GUIX_GLIBC_VERSION way. That one seems the clearest, at least to me... 2017-12-03 19:43 GMT+01:00 Marius Bakke : > Ricardo Wurmus writes: > > > Marius Bakke writes: > > > >> G=C3=A1bor Boskovits writes: > >> > >>> It seems, that we have a breakage in current core-updates. m4, > gettext, and > >>> at least a few other packages fail to build. > >> > >> Hello! > >> > >> The problem is that the glibc version string is used a couple of place= s > >> to determine where locales are found. > >> > >> The attached patch fixes it, though I'm not sure if it's the best > >> approach. Thoughts? > > > > Thank you. > > > > I find it a little ugly to replace the exact version string with only > > the major+minor version substring. Why can=E2=80=99t we use the full v= ersion > > string? > > I think it's because "glibc-versioned-locpath.patch" uses the libc > VERSION constant. > > Perhaps we could substitute glibcs "version.h", but that might break > other things. Or introduce a different variable, say > GUIX_GLIBC_VERSION, and use that. WDYT? > --089e082658b0568399055f74452c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd go the GUIX_GLIBC_VERSION way.

That o= ne seems the clearest, at least to me...

2017-12-03 19:43 GMT+01:00 Marius = Bakke <mbakke@fastmail.com>:
Ricardo Wurmus <rekado@elephly.net> writes:

> Marius Bakke <mbakke@fastmai= l.com> writes:
>
>> G=C3=A1bor Boskovits <bo= skovits@gmail.com> writes:
>>
>>> It seems, that we have a breakage in current core-updates. m4,= gettext, and
>>> at least a few other packages fail to build.
>>
>> Hello!
>>
>> The problem is that the glibc version string is used a couple of p= laces
>> to determine where locales are found.
>>
>> The attached patch fixes it, though I'm not sure if it's t= he best
>> approach.=C2=A0 Thoughts?
>
> Thank you.
>
> I find it a little ugly to replace the exact version string with only<= br> > the major+minor version substring.=C2=A0 Why can=E2=80=99t we use the = full version
> string?

I think it's because "glibc-versioned-locpath.patch&qu= ot; uses the libc
VERSION constant.

Perhaps we could substitute glibcs "version.h", but that might br= eak
other things.=C2=A0 Or introduce a different variable, say
GUIX_GLIBC_VERSION, and use that.=C2=A0 WDYT?

--089e082658b0568399055f74452c--