From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id +BqpBwCCdV/cBQAA0tVLHw (envelope-from ) for ; Thu, 01 Oct 2020 07:15:12 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id OLKtAwCCdV8mJwAA1q6Kng (envelope-from ) for ; Thu, 01 Oct 2020 07:15:12 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 8C94B94065D for ; Thu, 1 Oct 2020 07:15:11 +0000 (UTC) Received: from localhost ([::1]:50506 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kNso1-0004Pg-BK for larch@yhetil.org; Thu, 01 Oct 2020 03:15:09 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:48358) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kNsnu-0004PN-Ea for guix-patches@gnu.org; Thu, 01 Oct 2020 03:15:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:50576) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kNsnu-000228-4S for guix-patches@gnu.org; Thu, 01 Oct 2020 03:15:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kNsnt-00069g-Rn for guix-patches@gnu.org; Thu, 01 Oct 2020 03:15:01 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#43591] [PATCH core-updates] gnu: glibc-final: Catch all cases of a glibc user not requesting 64-bit offsets and then using readdir. Resent-From: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Thu, 01 Oct 2020 07:15:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43591 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Danny Milosavljevic Cc: 43591@debbugs.gnu.org, Marius Bakke Received: via spool by 43591-submit@debbugs.gnu.org id=B43591.160153646423601 (code B ref 43591); Thu, 01 Oct 2020 07:15:01 +0000 Received: (at 43591) by debbugs.gnu.org; 1 Oct 2020 07:14:24 +0000 Received: from localhost ([127.0.0.1]:33889 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kNsnI-00068a-81 for submit@debbugs.gnu.org; Thu, 01 Oct 2020 03:14:24 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41476) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kNsnF-00068L-Bg for 43591@debbugs.gnu.org; Thu, 01 Oct 2020 03:14:22 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49834) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kNsn9-0001zM-Iu; Thu, 01 Oct 2020 03:14:15 -0400 Received: from [2a01:e0a:1d:7270:af76:b9b:ca24:c465] (port=33336 helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kNsn7-0004E2-Bk; Thu, 01 Oct 2020 03:14:13 -0400 From: Ludovic =?UTF-8?Q?Court=C3=A8s?= References: <20200924141211.21649-1-dannym@scratchpost.org> <87363759at.fsf@gnu.org> <20200924222711.2f22281a@scratchpost.org> <87tuvm4vop.fsf@gnu.org> <87h7rg4879.fsf@gnu.org> <20200930000934.6812b7c8@scratchpost.org> <87tuvf1uet.fsf@gnu.org> <20200930122821.1471d155@scratchpost.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 10 =?UTF-8?Q?Vend=C3=A9miaire?= an 229 de la =?UTF-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu Date: Thu, 01 Oct 2020 09:14:10 +0200 In-Reply-To: <20200930122821.1471d155@scratchpost.org> (Danny Milosavljevic's message of "Wed, 30 Sep 2020 12:28:21 +0200") Message-ID: <87o8lmv2nx.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Spam-Score: -3.3 (---) X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Spam-Score: -1.51 X-TUID: Sz52On4y0GBS Hi, Danny Milosavljevic skribis: > On Wed, 30 Sep 2020 11:32:58 +0200 > Ludovic Court=C3=A8s wrote: > >> Dropping emulated builds, or at least 32-bit emulated builds. We just >> need to remove build machines from the file above. > > Oh. > > Do we have real armhf machines? (as in not aarch64) > > *Looks at guix-maintenance* We do. Awesome. Then sure. > > But just to be clear, WE MUST NOT USE aarch64 to build armhf as long as t= his > problem isn't fixed. > > This problem has nothing to do with emulation. Now I=E2=80=99m lost; I thought this had to do with qemu-user. Could you propose a patch for maintenance.git? > I want to know what actually changes in the final binaries. Surely that = works > somehow--guix data services or not. > > Basically, for each package in Guix, > > diff -r `~/broken-guix/pre-inst-env guix build $package` `~/fixed-guix/= pre-inst-env guix build $package` || echo "affected: $package" > > but after replacing references by deduplicated content addressed referenc= es > (for example if derivation A refers to files in derivation B, but derivat= ion B > only changed the directory name it's in and not the content of the deriva= tion, > then that should not count as a diff in A. That should happen recursivel= y). Yeah, you =E2=80=9Cjust=E2=80=9D need to compare modulo store file names=E2= =80=A6 >> I have mixed feelings: fixing packages one by one doesn=E2=80=99t sound = great, >> but OTOH setting the =E2=80=98CFLAGS=E2=80=99 environment variable globa= lly can have >> unexpected side effects in some cases (overriding package-specific >> CFLAGS) and zero effects in other cases (for non-Autoconf packages or >> badly-written =E2=80=98configure.ac=E2=80=99 files), both of which would= be hard to >> detect. > > The latter is easy to detect since I patched dirent.h in glibc exactly fo= r that > reason. That way, glibc WON'T let you use it wrong (except if you explic= itly > ask for it). On Guix systems, there is no legitimate reason to use it wr= ong > in the first place. I=E2=80=99m very reluctant to patching public libc headers. Also, it=E2=80= =99s not just =E2=80=9Cour=E2=80=9D problem, we should definitely discuss it with upstrea= m and perhaps propose your dirent.h patch. I=E2=80=99m also not sure what you mean by =E2=80=9Cusing it wrong=E2=80=9D= , what is =E2=80=9Cit=E2=80=9D? Building without _FILE_OFFSET_BITS=3D64 is still a valid option, albeit one that is not recommended. > About the unexpected side effects--yes, that's right. That's why we shou= ld get > a list of diff results (see above for the command) and then manually look= at > the source code of those packages and their dependencies. A diff at one point in time (if we ever managed to get a usable diff) is not enough: problems could pop up anytime. Setting =E2=80=98CFLAGS=E2=80= =99 globally as an environment variable seems risky. >> If we take a step back: what=E2=80=99s the problem? > > It means we have no trustworthy i686 packages, which means we do not have= a > trustworthy full source bootstrap using Mes (since that uses i686 executa= ble > to bootstrap). > > In practice, this problem is not so bad since the kernel on i686 has a co= mpat > layer that hasn't been telling us the truth for d_off, so we should be "g= ood". > But philosophically, we are doing it dead wrong. > > Also, this won't work on armhf or any other 32 bit architecture--so there, > we would be both philosophically and practically wrong. > > Also, the "not telling us the truth for d_off on i686" is a leaky compat = layer. > It totally DOES wind up telling us the truth sometimes (see my earlier te= st > table)--and then we have a problem. Hmm I guess I need to re-read all that, I=E2=80=99m overwhelmed. Thanks, Ludo=E2=80=99.