public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: "Rasmus Villemoes" <rasmus.villemoes@prevas.dk>
To: OE Core mailing list <openembedded-core@lists.openembedded.org>
Cc: "Richard Purdie" <richard.purdie@linuxfoundation.org>,
	"Kjeld Flarup" <kfa@deif.com>,
	"Per Nørgaard Christensen" <per.christensen@prevas.dk>,
	"Paul Eggleton" <paul.eggleton@linux.intel.com>,
	"Kurt Østergaard Frandsen" <kof@deif.com>
Subject: file checksums versus SRC_URI globs
Date: Wed, 1 Jul 2020 15:51:19 +0200	[thread overview]
Message-ID: <aaad9ac7-be6a-1ffb-6990-ab371ed40015@prevas.dk> (raw)

Hi,

We have a recipe that uses

  SRC_URI += "file://somedir/*"

and we have noticed that changing one of the files inside somedir does
not cause the recipe to be rebuilt - in fact, no task hashes are
affected; we discovered this because a clean build worked correctly,
while one that uses an sstate mirror would end up with an old version of
those files on the target.

Digging around, it _seems_ that this should be supported, e.g.

commit bb66113bde5361b869dce2bdaece5b938f077ea8
Author: Richard Purdie <richard.purdie@linuxfoundation.org>
Date:   Sun Apr 6 11:08:22 2014 +0100

    bitbake: fetch2: Fix bug in file checksum generation

However, it also seems that something since then has broken the
checksumming of files specified via a glob pattern. At least if I take
the recipe mentioned in that commit and run "bitbake-dumpsig -t
connman-gnome do_fetch", I get

Variable SRC_URI value is
git://github.com/connectivity/connman-gnome.git
file://0001-Removed-icon-from-connman-gnome-about-applet.patch
 file://null_check_for_ipv4_config.patch            file://images/*
      file://connman-gnome-fix-dbus-interface-name.patch
file://0001-Port-to-Gtk3.patch
...
This task depends on the checksums of files:
[('0001-Removed-icon-from-connman-gnome-about-applet.patch',
'4c1b4d89f92949f34d5c232d85398bb4'),
('connman-gnome-fix-dbus-interface-name.patch',
'51f2ebbc91ec35184876dfdf8aec35fd'),
('null_check_for_ipv4_config.patch',
'a23271e41c9fe81551244d875106af10'), ('0001-Port-to-Gtk3.patch',
'fa8ffcd77c330fd5063c7a7c62dd7c69')]

i.e., none of the files in images/ are mentioned, contrary to what was
apparently the case back in 2014.

Rasmus

             reply	other threads:[~2020-07-01 13:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-01 13:51 Rasmus Villemoes [this message]
2020-07-01 14:03 ` [OE-core] file checksums versus SRC_URI globs Quentin Schulz
2020-07-02  6:42   ` Rasmus Villemoes
     [not found]   ` <161DDC5BD88A8AE5.10798@lists.openembedded.org>
2020-07-09 19:31     ` Rasmus Villemoes
2020-08-25 14:03       ` Richard Purdie
     [not found]     ` <16202C67498F91AC.11682@lists.openembedded.org>
2020-08-05  8:21       ` Rasmus Villemoes

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=aaad9ac7-be6a-1ffb-6990-ab371ed40015@prevas.dk \
    --to=rasmus.villemoes@prevas.dk \
    --cc=kfa@deif.com \
    --cc=kof@deif.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=paul.eggleton@linux.intel.com \
    --cc=per.christensen@prevas.dk \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox