Hey Richard,
On 3/15/2020 4:48 AM, Richard Purdie wrote:
On Sat, 2020-03-14 at 23:13 -0700, Alejandro Hernandez Samaniego wrote:
Due to the architectural changes between Windows Subsystem for Linux
v2, and WSL v1 it should now be possible to run bitbake on the
several distros offered through the Microsoft Store.
WSLv2 is available on Windows 10 build number > 18917
The current build number may be checked by opening a cmd prompt on
Windows and running:
C:\Users\myuser>ver
Microsoft Windows [Version 10.0.19041.113]
Thanks, this is useful information. How much of our system works on
WSL2? runqemu? testimage? eSDK? virtgl? Is anything known not to work?
This email implies everything works?
My big worry here is that we have a set subset of bugs which only occur
on WSL2. We're struggling with the bug reports we have today, adding in
a whole new set with no help to support that is a concern.
I have tested enough to be confident that this should not be the case,
testimage works,
runqemu works (after creating the tap interfaces), unless you have specific
tests that
you want me to run for virtgl, I did test virtgl on runqemu and ran the image
along with
some basic graphics testing, esdk works, I just ran bitbake-selftest and
oe-selftest and
they both work, I understand your concern but I dont believe this would be the
case.
Is this for 3.1 LTS? Are Microsoft going to be able to help us in any
way? How "official" is this change?
I can speak for myself and say that if there are any WSL related bugs, they can
be assigned
to me during TRIAGE and I will take a look at them, also note that these are
only the
changes on the OE part of things, WSLv2 will be generally available on Windows
10 v2004
https://devblogs.microsoft.com/commandline/wsl2-will-be-generally-available-in-windows-10-version-2004/
So, while my hope is that this can be merged on Dunfell, if possible I'd like
to backport
this to Zeus at least, note that the previous check simply won't work on WSLv2
and it wont
throw any errors about it, I believe people will start using this regardless
and its better
if we warn them properly about the process (I have tested both current master
and Zeus).
If that is not possible then at the very least we should throw an error as well
for WSLv2 on
previous releases.
if "Microsoft" in l:
- return "OpenEmbedded doesn't work under WSL at this time, sorry"
+ return "OpenEmbedded doesn't work under WSLv1, please upgrade to WSLv2
if you want to run builds on Windows"
+ elif "microsoft" in l:
+ bb.warn("You are running bitbake under WSLv2, this works properly but
you should optimize your VHDX file eventually to avoid running out of storage space")
return None
# Tar version 1.24 and onwards handle overwriting symlinks correctly
Is Microsoft vs microsoft the best check we can have? Should we be
checking the version specifically?
AFAIC this is a good way to test it, it is kept across all Microsoft Store
Distros for both WSLv1 and WSLv2.
Cheers,
Alejandro
Cheers,
Richard
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
