From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id DDAAFC369D5 for ; Thu, 24 Apr 2025 14:50:54 +0000 (UTC) Subject: Re: [PATCH] glibc-y2038-tests:add tests-special in run-built-tests yes To: openembedded-core@lists.openembedded.org From: "rajmohan r" X-Originating-Location: IN (136.226.253.31) X-Originating-Platform: Linux Chrome 135 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Thu, 24 Apr 2025 07:50:50 -0700 References: In-Reply-To: Message-ID: <28087.1745506250655631551@lists.openembedded.org> Content-Type: multipart/alternative; boundary="Tqggh4tUKH48kkqXbzDR" List-Id: X-Webhook-Received: from li982-79.members.linode.com [45.33.32.79] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Thu, 24 Apr 2025 14:50:54 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/openembedded-core/message/215382 --Tqggh4tUKH48kkqXbzDR Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 22, 2025 at 03:52 PM, Alexander Kanavin wrote: >=20 > On Tue, 22 Apr 2025 at 13:03, rajmohan r via lists.openembedded.org > wrote: >=20 >> On Thu, Apr 10, 2025 at 07:34 PM, Alexander Kanavin wrote: >>=20 >> Thanks. This patch is invasive and adds to glibc maintenance burden. >> Which begs the question: do we need the recipe at all? Is there a >> particular reason you started looking into this issue? >>=20 >> When we moved from yocto kirkstone branch to scarthgap branch, we found >> that >> compilation for this module taking longer time. hence started looking >> which stage >> in this module takes time. Found that it is in do_check() stage. >>=20 >>=20 >> It is by now well established that glibc itself works as it should, >> that all affected 32 bit targets are configured to use 64 bit time_t, >> and that any lingering y2038 issues are in components other than the c >> library, and usually come from C programming mistakes (e.g. storing >> timestamps in long). Maybe we can simply remove the recipe? >>=20 >> This recipe gives only two test cases in the packages to test. below are >> the >> test cases seen for this package >> io/ftwtest >> io/ftwtest-time64 >=20 > Right. I propose that this recipe be altogether removed (with the > rationale I provided above which you can add to the commit message). > Can you send a patch for that? Patch is send here https://lists.openembedded.org/g/openembedded-core/messa= ge/215381 please review. Thanks for reviewing. >=20 > Alex --Tqggh4tUKH48kkqXbzDR Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
On Tue, Apr 22, 2025 at 03:52 PM, Alexander Kanavin wrote:
On Tue, 22 Apr 2025 at 13:03, rajmohan r via lists.openembedded= .org
<semc.2042=3Dgmail.com@lists.openembedded.org> wrote:
On Thu, Apr 10, 2025 at 07:34 PM, Alexander Kanavin wrote:

Thanks. This patch is invasive and adds to glibc maintenance burden.=
Which begs the question: do we need the recipe at all? Is there a
particular reason you started looking into this issue?

When we= moved from yocto kirkstone branch to scarthgap branch, we found that
= compilation for this module taking longer time. hence started looking which= stage
in this module takes time. Found that it is in do_check() stage= .


It is by now well established that glibc itself works as= it should,
that all affected 32 bit targets are configured to use 64 = bit time_t,
and that any lingering y2038 issues are in components othe= r than the c
library, and usually come from C programming mistakes (e.= g. storing
timestamps in long). Maybe we can simply remove the recipe?=

This recipe gives only two test cases in the packages to test. = below are the
test cases seen for this package
io/ftwtest
io= /ftwtest-time64
Right. I propose that this recipe be altogether removed (with the
rati= onale I provided above which you can add to the commit message).
Can y= ou send a patch for that?
Patch is send here https://lists.open= embedded.org/g/openembedded-core/message/215381 please review. Thanks f= or reviewing.
Alex
--Tqggh4tUKH48kkqXbzDR--