On Tue, 2020-08-25 at 11:13 +0200, Rasmus Villemoes wrote:
> There are a couple of problems with do_populate_lic, especially
> around
> the kernel and u-boot recipes.
> 
> First, we have a race condition in kernel recipes:
> 
> addtask populate_lic after do_patch before do_build
> addtask symlink_kernsrc before do_configure after do_unpack
> 
> so there's no ordering between those two tasks. I have in fact seen
> do_populate_lic fail because (part of) it runs just between the two
> lines
> 
>             shutil.move(s, kernsrc)
>             os.symlink(kernsrc, s)
> 
> WARNING: Could not copy license file /mnt/...
> ...
> ERROR: QA Issue: ...: LIC_FILES_CHKSUM points to an invalid file:
> 
> and it's fairly easy to reproduce with a monkey-patch:
> 
> @@ -148,7 +148,9 @@ python do_symlink_kernsrc () {
>              os.symlink(s, kernsrc)
>          else:
>              import shutil
> +            import time
>              shutil.move(s, kernsrc)
> +            time.sleep(15)
>              os.symlink(kernsrc, s)
>  }
> 
> I think this could be fixed by making symlink_kernsrc run before
> do_patch rather than do_configure - in fact, AFAICT, there's the exact
> same lack of ordering with do_patch, it's just that nobody usually has
> any .patch files for the kernel when it's maintained in git.

I agree with that solution, please send a patch for that.

> Second, as I've reported previously [1], creating hard-links to files in
> kernel or u-boot source repositories, as do_populate_lic does, leads
> to scripts/setlocalversion falsely appending a "-dirty" string. It
> doesn't happen if one is building a kernel containing ff64dd485730 or
> a backport of it (e.g. v5.0+, v4.19.82+) _and_ one has git >= 2.14.
> U-Boot hasn't
> copied ff64dd485730 yet, so it can always happen for U-Boot. Since
> there's no ordering between do_populate_lic and do_compile, it's not
> even deterministic whether that -dirty string is appended. So while
> appropriate tools and patched upstream projects will make the problem
> go
> away, I'm wondering the hardlink optimization is really worth the
> trouble it causes.
> 
> [1] https://lists.openembedded.org/g/openembedded-core/message/137702

We use hardlinks a lot and it does help for disk IO and performance.
Has this issue been raised with u-boot upstream? They're usually
helpful and there are a few of the maintainers using OE so I think
they'd want to fix this if they know about it.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141811): 
https://lists.openembedded.org/g/openembedded-core/message/141811
Mute This Topic: https://lists.openembedded.org/mt/76403349/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to