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
next 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