[From nobody Sat Mar 28 17:35:06 2026 Received: (at 1128926-done) by bugs.debian.org; 28 Mar 2026 17:32:32 +0000 X-Spam-Checker-Version: SpamAssassin 4.0.1-bugs.debian.org_2005_01_02 (2024-03-25) on buxtehude.debian.org X-Spam-Level: X-Spam-Status: No, score=-109.1 required=4.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FOURLA, FROMDEVELOPER,HAS_BUG_NUMBER,MD5_SHA1_SUM,SPF_HELO_NONE,SPF_NONE, UNPARSEABLE_RELAY,USER_IN_DKIM_WELCOMELIST autolearn=ham autolearn_force=no version=4.0.1-bugs.debian.org_2005_01_02 X-Spam-Bayes: score:0.0000 Tokens: new, 8; hammy, 150; neutral, 102; spammy, 0. spammytokens: hammytokens:0.000-+--Hx-spam-relays-external:sk:stravin, 0.000-+--H*RT:sk:stravin, 0.000-+--Hx-spam-relays-external:311, 0.000-+--H*RT:311, 0.000-+--H*RT:108 Return-path: <aurel32@debian.org> Received: from stravinsky.debian.org ([2001:41b8:202:deb::311:108]:40080) by buxtehude.debian.org with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from <aurel32@debian.org>) id 1w6XWS-00B0yv-2F for 1128926-done@bugs.debian.org; Sat, 28 Mar 2026 17:32:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:To:From:Date:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description; bh=BjWdu4+TwoViVOT4y3uJR8OLT4FcQWp+PLgAII7xnMc=; b=wAAF0Pz8pPEoE2YxZCZUv6/pGI Iobgdlc1mnv4JgXCWC7EdJ0MCDa3MZ5B05SLbW67X7pH5qWoG7Axsh9//j9Q4DoDuI48WRVUzmw4H qXPr7QqEf+1B4a/Oz+mLIprT9K9NfpNTgEiwywEy2MOoVakVfhIbqEaOP99uceyxjxuJiHiIvTkfi Yy/QAjEhGkpFCLxV71PAvJoAer3GNMaQ2keKjK2iMpgVZfOClz0A1rYYgjcSdjltAew3LbituglQ4 mbr4GWflzWP+zne5rNEBEAEAU8pIWuSsrwWVbygqwGUltZaAMT+357hjNnrnkNEsonTQNnFdScY1G eE2WaRbQ==; Received: from authenticated user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from <aurel32@debian.org>) id 1w6XWR-0004LI-3D for 1128926-done@bugs.debian.org; Sat, 28 Mar 2026 17:32:31 +0000 Received: from authenticated user by hall.aurel32.net with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from <aurel32@debian.org>) id 1w6XWQ-00000001B9k-0njP for 1128926-done@bugs.debian.org; Sat, 28 Mar 2026 18:32:30 +0100 Date: Sat, 28 Mar 2026 18:32:29 +0100 From: Aurelien Jarno <aurel32@debian.org> To: 1128926-done@bugs.debian.org Subject: Re: Bug#1128926: yorick-yeti: FTBFS with glibc 2.43 on arm64, issue with 2MB THP Message-ID: <acgQreDiBwblhdd_@aurel32.net> References: <aZ3NL1oF0PpKdFtu@ariel.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <aZ3NL1oF0PpKdFtu@ariel.home> User-Agent: Mutt/2.2.13 (2024-03-09) X-Debian-User: aurel32 On 2026-02-24 17:09, Emanuele Rocca wrote: > Source: yorick-yeti > Version: 6.4.0-2 > Severity: important > Tags: ftbfs upstream > Justification: fails to build from source > User: debian-glibc@lists.debian.org > Usertags: glibc-2.43 > > Hi, > > yorick-yeti fails to build from source on arm64 when using glibc 2.43, > currently in experimental. > > The issue is triggered by glibc 2.43 on arm64 enabling 2MB THP by > default: > https://sourceware.org/git/?p=glibc.git;a=commit;h=321e1fc73f53081d92ba357cdd48c56b79292020 > > Successful build with glibc 2.42, currently in sid: > https://people.debian.org/~ema/glibc-2.43-rebuilds/output-2/yorick-yeti_arm64.build > > Logs of a failed build with glibc 2.43 are here: > https://people.debian.org/~ema/glibc-2.43-rebuilds/output-1/yorick-yeti_arm64.build > > The following test is failing: > > ERROR (__dft_op) mathlib function signals error > LINE: 67 FILE: /build/reproducible-path/yorick-yeti-6.4.0/fftw/yeti_fftw_test.i > > Notably, the problem cannot be reproduced when building the package with > dpkg-buildpackage, while it can be reproduced with sbuild. An important > difference between the two environments is that sbuild has an empty > /sys/kernel/, and glibc 2.43 checks if THP are enabled by looking under > /sys/kernel/mm/transparent_hugepage/enabled. > > See https://bugs.debian.org/1128916 for a somehow related issue. Starting with glibc 2.43-2, glibc does not check for /sys/kernel/mm during malloc, which fixes the issue. I am therefore closing the bug. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://aurel32.net]