From: "Rasmus Villemoes" <rasmus.villemoes@prevas.dk>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: "Quentin Schulz" <quentin.schulz@streamunlimited.com>,
"OE Core mailing list" <openembedded-core@lists.openembedded.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: Re: [OE-core] file checksums versus SRC_URI globs
Date: Wed, 5 Aug 2020 10:21:28 +0200 [thread overview]
Message-ID: <1b9d5481-a933-4d47-0673-71e688ae4e25@prevas.dk> (raw)
In-Reply-To: <16202C67498F91AC.11682@lists.openembedded.org>
On 09/07/2020 21.31, Rasmus Villemoes via lists.openembedded.org wrote:
> On 02/07/2020 08.42, Rasmus Villemoes via lists.openembedded.org wrote:
>> On 01/07/2020 16.03, Quentin Schulz wrote:
>>> Hi Rasmus,
>>>
>>> On Wed, Jul 01, 2020 at 03:51:19PM +0200, Rasmus Villemoes wrote:
>>>> Hi,
>>>>
>>>> We have a recipe that uses
>>>>
>>>> SRC_URI += "file://somedir/*"
>>>>
>>>
>>> Glob aren't supported. Use "file://somedir/" instead.
>>
>> Thanks, that actually works for one of the cases we have (there are
>> others that use globs which cannot be solved quite that simply, but for
>> now I'm just listing files explicitly instead).
>>
>> However, I'm not sure that "globs aren't supported". The commit I
>> referenced clearly tried to make that work (better), it also "works" in
>> the sense of unpacking the expected things when building from scratch -
>> there's even
>>
>> def test_local_wildcard(self):
>> tree = self.fetchUnpack(['file://a', 'file://dir/*'])
>> self.assertEqual(tree, ['a', 'dir/c', 'dir/d', 'dir/subdir/e'])
>>
>> in bitbake/lib/bb/tests/fetch.py. And the two upstream recipes
>> connman-gnome_0.7.bb and matchbox-desktop_2.2.bb both use that exact
>> pattern.
>>
>> So either
>>
>> - this is a plain bug in the signature computation,
>
> I'm guessing the culprit is
>
> commit 6c0706a28d72c591f1b75b6e3f3b645859387c7e
> Author: Richard Purdie <richard.purdie@linuxfoundation.org>
> Date: Mon Dec 8 21:25:23 2014 +0000
>
> cache/fetch2/siggen: Ensure we track include history for file checksums
>
> which was the one that introduced the ":True: or ":False" suffixing via
>
> + filelist.append(f + ":" + str(os.path.exists(f)))
>
> and then also did
>
> @@ -981,6 +980,10 @@ def get_file_checksums(filelist, pn):
>
> checksums = []
> for pth in filelist.split():
> + exist = pth.split(":")[1]
> + if exist == "False":
> + continue
> + pth = pth.split(":")[0]
> if '*' in pth:
> # Handle globs
> for f in glob.glob(pth):
>
> which practically guaranteed that the "if '*' in pth" would be dead code.
>
> Richard, do you agree that this is a bug in the signature computation?
Richard, ping?
Rasmus
prev parent reply other threads:[~2020-08-05 8:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-01 13:51 file checksums versus SRC_URI globs Rasmus Villemoes
2020-07-01 14:03 ` [OE-core] " 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 [this message]
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=1b9d5481-a933-4d47-0673-71e688ae4e25@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=quentin.schulz@streamunlimited.com \
--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