All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paulo Neves <ptsneves@gmail.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: bitbake-devel@lists.openembedded.org
Subject: Re: [bitbake-devel] [PATCH 1/2] fetch2: local files only in DL_DIR becomes fatal error
Date: Sat, 9 Jul 2022 09:19:44 +0200	[thread overview]
Message-ID: <CAJO0J4g4cyPLGEQ1s4v8cMk0RTgGKGtoh3GME=9Sx+D0KQLX3A@mail.gmail.com> (raw)
In-Reply-To: <c677e1a7cedcd974e9ecd6b0bb4aefdcd240932f.camel@linuxfoundation.org>

[-- Attachment #1: Type: text/plain, Size: 3181 bytes --]

On Sat, Jul 9, 2022, 08:52 Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> On Fri, 2022-07-08 at 22:54 +0200, Paulo Neves wrote:
> > When trying to checksum local files, if a given file is not found
> > anywhere else than the DL_DIR then this means that the the build is
> > inconsistent, and unreproducible.
> >
> > This also means that if the DL_DIR is removed or not available the
> > build does not know how to fetch the file and will fail. With this
> > commit we fail earlier and consistently on this condition.
> >
> > Signed-off-by: Paulo Neves <ptsneves@gmail.com>
> > ---
> >  lib/bb/fetch2/__init__.py | 4 +++-
> >  lib/bb/tests/fetch.py     | 7 +++++++
> >  2 files changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/bb/fetch2/__init__.py b/lib/bb/fetch2/__init__.py
> > index ac557176..5f05278a 100644
> > --- a/lib/bb/fetch2/__init__.py
> > +++ b/lib/bb/fetch2/__init__.py
> > @@ -1233,7 +1233,9 @@ def get_checksum_file_list(d):
> >                  if f.startswith(dl_dir):
> >                      # The local fetcher's behaviour is to return a path
> under DL_DIR if it couldn't find the file anywhere else
> >                      if os.path.exists(f):
> > -                        bb.warn("Getting checksum for %s SRC_URI entry
> %s: file not found except in DL_DIR" % (d.getVar('PN'),
> os.path.basename(f)))
> > +                        bb.fatal(("Getting checksum for %s SRC_URI
> entry %s: file not found except in DL_DIR."
> > +                            " This means there is no way to get the
> file except for an orphaned copy"
> > +                            " in DL_DIR.") % (d.getVar('PN'),
> os.path.basename(f)))
> >                      else:
> >                          bb.warn("Unable to get checksum for %s SRC_URI
> entry %s: file could not be found" % (d.getVar('PN'), os.path.basename(f)))
> >                  filelist.append(f + ":" + str(os.path.exists(f)))
>
> Did you manage to trigger that error in a real world use case?
>
> I've just been looking at this code and it is horribly old and
> outdated. I can't help wonder if we shouldn't do something a bit more
> invasive to clean it up a bit more. I suspect it does some of these
> things for old/obsolete reasons...
>
> I ask since I'm wondering if anyone ever hits these code paths in a
> valid usecase.
>
> Thanks for working on it, we do need to improve some of these things.
>
> Cheers,
>
> Richard
>

Hey Richard,

I think these codepaths are hit on mostly on bugs(bad uri parsing) or bad
files(bad permissions).

The use case i added on the tests is also clearly bad, but I have seen
builds going on for very long in the state of warning, which becomes fatal
with the patch, because the dl_dir was stable and used by all users. So
expect this patch to increase the reports of latent issues people just
ignored.

Yesterday I also hit this warning organically exactly on the situation of
the test: a directory mentioned on the SRC_URI which did not exist in any
FILESPATHS but somehow existed on the dl_dir. So it is real.

I will investigate the whole default to dl_dir if not found and remove it
if I cannot find a good reason.

Paulo Neves

>

[-- Attachment #2: Type: text/html, Size: 4447 bytes --]

  reply	other threads:[~2022-07-09  7:20 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-08 20:54 [PATCH 1/2] fetch2: local files only in DL_DIR becomes fatal error Paulo Neves
2022-07-08 20:54 ` [PATCH 2/2] fetch: bb.fatal when trying to checksum non-existing files Paulo Neves
2022-07-13  9:48   ` [bitbake-devel] " Alexandre Belloni
2022-07-13 10:10     ` Paulo Neves
2022-07-13 12:28       ` Richard Purdie
2022-07-26  4:09   ` Patrick Williams
2022-07-26  5:35     ` [bitbake-devel] " Alexander Kanavin
2022-07-26 15:57       ` Patrick Williams
2022-07-27 12:00         ` Alexander Kanavin
2022-07-27 14:50         ` Quentin Schulz
2022-07-27 19:16           ` Patrick Williams
2022-07-26  6:39     ` Richard Purdie
2022-07-26  7:01       ` Paulo Neves
2022-07-26 16:01         ` Patrick Williams
2022-07-09  6:52 ` [bitbake-devel] [PATCH 1/2] fetch2: local files only in DL_DIR becomes fatal error Richard Purdie
2022-07-09  7:19   ` Paulo Neves [this message]
     [not found]     ` <a7dffab1-9b0c-fab8-a538-81c3d0065834@gmail.com>
2022-07-09 13:20       ` Richard Purdie

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='CAJO0J4g4cyPLGEQ1s4v8cMk0RTgGKGtoh3GME=9Sx+D0KQLX3A@mail.gmail.com' \
    --to=ptsneves@gmail.com \
    --cc=bitbake-devel@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.org \
    /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.