All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Richard Purdie" <richard.purdie@linuxfoundation.org>
To: Jose Quaresma <quaresma.jose@gmail.com>
Cc: OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] [PATCH] sstate.bbclass: adds warnings for the exceptions of os.utime in siginfo
Date: Mon, 04 Oct 2021 21:03:42 +0100	[thread overview]
Message-ID: <42ad79c92bea355abe2d7d7200003f62d6e3a212.camel@linuxfoundation.org> (raw)
In-Reply-To: <CANPvuR=Gnc=QpXqQkC1=37=93SZC1f_MS8FvfLui8RKmx9r5hQ@mail.gmail.com>

On Mon, 2021-10-04 at 18:59 +0100, Jose Quaresma wrote:
> I understand the exception for the use cases but I think it would be useful
> to show this to the users. Will it be more appropriate perhaps to log this as
> debug messages?

The trouble is in the situations that is guarding against, the user cannot do
anything about it so warnings definitely aren't appropriate and I'm not sure
debug messages would be welcome either. Those would be less invasive though.

> I have a final question that I don't understand clearly.
> Can the omission of these timestamps updates on siginfo invalidate the use of
> the sstate-cache for that task,
> bitbake-dumpsig can complain about that?

I think there is a misunderstanding here. The timestamps I've been talking about
are part of reproducible builds and the SOURCE_DATE_EPOCH variable and code.
These aim to make the output identical. If the output is identical, hash
equivalence is more successful and the more successful hash equivalence is, the
more sstate reuse you get.

The timestamps in this part of the sstate code are simply there to handle sstate
artefact aging (e.g. delete things which haven't been used in X weeks). The
timestamp change is therefore "nice" but if it doesn't happen, it isn't a
problem. Hope that helps clarify.

Cheers,

Richard



  reply	other threads:[~2021-10-04 20:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-03 21:38 [PATCH] sstate.bbclass: adds warnings for the exceptions of os.utime in siginfo Jose Quaresma
2021-10-04 14:11 ` [OE-core] " Richard Purdie
2021-10-04 17:59   ` Jose Quaresma
2021-10-04 20:03     ` Richard Purdie [this message]
2021-10-06  8:10       ` Jose Quaresma

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=42ad79c92bea355abe2d7d7200003f62d6e3a212.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=quaresma.jose@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.