Trouble with getting started

[Trophime]

Hi, this must be a pretty dumb question from a newbie but I cannot figure out to complete 1st step of Getting started. More precisely I cannot find the "Packaging tab"?

I'm using Visual studio 2019 community Edition (in French :( on top of that). Do I need some specific extensions?

Thanks for your help. I really wish to build my own distrib. Best

[imaandrew]

Did you open the DistroLauncher-Appx/MyDistro.appxmanifest file with Visual Studio? The packaging tab only shows up when you open it.

[Trophime]

Could you please show me where the packaging tab shall be?

[imaandrew]

You need to open the solution first. First, open the DistroLauncher.sln file with Visual Studio. Second, double click on DistroLauncher-Appx (Universal Windows). It should be on the right side of the screen. Third, double click on the MyDistro.appxmanifest file that appeared below DistroLauncher-Appx (Universal Windows).

[imaandrew]

Here is what you do.

[Trophime]

That's a lot for this tuto. I'll give a trial and let you known if I manage to get it work. Best

[Trophime]

OK thanks it helps but I still cannot figure out the whole process. I've tried to rebuild a debian Buster version from debian/WSL salsa repository. I tried to change the name of the distrib to MyDebian10 and change the images in assets. I can build the package and run it with the debugger but lsb_release -cs keeps on answering stretch...

What I don't ketch is step 2):

• what exactly needs to be change in DistributionInfo.h? I think I don't need any change in the cop file..

and mostly step 6):

• How can I change values in MyDistro.appxmanifest?

These must be some really dummy questions. I really wish to understand the process. Thanks for your help

[imaandrew]

The DistributionInfo.h file contains information specific to your distribution.

To change the name of the distro, you would change Debian in the line const std::wstring Name = L"Debian"; to whatever you wanted to name your distribution.

The line const std::wstring WindowTitle = L"Debian"; dictates the title of the console while the distro is installing.

MyDistro.appxmanifest is an xml document which can be opened with a text editor such as notepad.

[Trophime]

To change the name of the distro, you would change Debian in the line const std::wstring Name = L"Debian"; to whatever you wanted to name your distribution.

I'm mixed up with step 4) Changing the distro name in DistributionInfo.h to lets say mydebian, mean that debian.exe shall be replaced by mydebian.exe in MyDistro.appxmanifest. Is that it?

[imaandrew]

I don't know if they both need to be the same, but to be safe, it's probably best that they are.

[Trophime]

MyDistro.appxmanifest.log

Here what I get for the attached manifest:

• A error message from git Opening repositories: C:\Users\trophime\Documents\Salsa\debian\nWSL Git failed with a fatal error. git-lfs filter-process: git-lfs: command not found fatal: the remote end hung up unexpectedly

• when Buillding: 1>------ Build started: Project: launcher, Configuration: Debug x64 ------ 1>Compiling Messages... 1>MC: Compiling C:\Users\trophime\Documents\Salsa\debian\nWSL\DistroLauncher\messages.mc 1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(231,5): warning MSB8065: Custom build for item "messages.mc" succeeded, but specified output "c:\users\trophime\documents\salsa\debian\nwsl\distrolauncher\msg0409.bin" has not been created. This may cause incremental build to work incorrectly. 1>stdafx.cpp 1>DistributionInfo.cpp 1>DistroLauncher.cpp 1>Helpers.cpp 1>WslApiLoader.cpp 1>Generating Code... 1>DistroLauncher.vcxproj -> C:\Users\trophime\Documents\Salsa\debian\nWSL\x64\Debug\launcher.exe 1>Done building project "DistroLauncher.vcxproj". 2>------ Build started: Project: LncmiDebian, Configuration: Debug x64 ------ 2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppBuild.targets(467,5): warning MSB8028: The intermediate directory (x64\Debug) contains files shared from another project (MyDebian10.vcxproj). This can lead to incorrect clean and rebuild behavior. 2>Copy C:\Users\trophime\Documents\Salsa\debian\nWSL\x64\Debug\launcher.exe into C:\Users\trophime\Documents\Salsa\debian\nWSL\x64\Debug\LncmiDebian\debian.exe 2> 1 fichier(s) copié(s). 2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(231,5): warning MSB8064: Custom build for item "debian" succeeded, but specified dependency "c:\users\trophime\documents\salsa\debian\nwsl\distrolauncher-appx\debian" does not exist. This may cause incremental build to work incorrectly. 2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(231,5): warning MSB8065: Custom build for item "debian" succeeded, but specified output "c:\users\trophime\documents\salsa\debian\nwsl\distrolauncher-appx\debian.exe" has not been created. This may cause incremental build to work incorrectly. 2>MyDistro.appxmanifest(14,6): warning APPX0006: This project uses the 'runFullTrust' capability. You should use the Windows Application Packaging Project to produce the store and sideload packages. See https://go.microsoft.com/fwlink/?linkid=871803 for more information. 2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VisualStudio\v16.0\AppxPackage\Microsoft.AppXPackage.Targets(2916,5): error APPX0702: Payload file 'C:\Users\trophime\Documents\Salsa\debian\nWSL\x64\Debug\DistroLauncher-Appx\debian.exe' does not exist. 2>MyDistro.appxmanifest : error APPX0703: Manifest references file 'lncmidebian.exe' which is not part of the payload. 2>Done building project "DistroLauncher-Appx.vcxproj" -- FAILED. ========== Build: 1 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

[imaandrew]

Did you rename anything that was once DistroLauncher-Appx? If something is named DistroLauncher-Appx, it needs to stay as that.

[Trophime]

I did follow step5 which is not needed then?

[imaandrew]

Please ignore that last message, it's actually launcher which should not be renamed and that doesn't seem to be the problem here. Could you make sure that the value of TargetName in DistroLauncher-Appx.vcxproj is the same as the value of Executable in MyDistro.appxmanifest

[Trophime]

ok I'll give it a trial tomorrow... I've just erased everything to restart from scratch... The "getting started" is definitively not clear enough for newbie like me :( Thanks for your help

[imaandrew]

I think I might know what's going wrong. If you still have them, could you please attach the MyDistro.appxmanifest and the DistroLauncher-Appx.vcxproj files.

[Trophime]

I manage to build the project with the names I pickup. Indeed ``TargetNameshall be changed tomydistro`. My confusion stems from the fact that TargetName is never mentioned in the getting started guy. However running the deployed solution from the debugger in VS still tells me that I'm running stretch whereas install.tar.gz correspond to buster :((

Is this problem related to the git-lfs message? (seems like VS does not support git-lfs) Where shall I put the rootfs file for my distribution to build and test it properly?

Here are my config files for the project: myconfig.zip

[rhaist]

Hi @Trophime - I am the maintainer for Debian WSL. The latest version can be found here: https://salsa.debian.org/debian/WSL

I always do Git + LFS outside of Visual Studio. To build the latest tar.gz you can either use a Debian based WSL2 (Debian & Ubuntu should work) and you should install prerequisites:

$ git clone https://salsa.debian.org/debian/WSL.git
$ cd WSL
$ sudo apt install cdebootstrap chroot qemu-user-static
$ ./create-targz.sh

qemu-user-static is only needed for the ARM build and qemu will only run in WSL2 not WSL1.

Deploying the build app on your local machine might clash with already installed version of the Debian app from the store. I would recommend testing the appbundle on a virtual machine. Microsoft provides free 90 days developer machines: https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/

I hope this was helpful. If not, just send me a message.

[Trophime]

Thanks for the tip. Unfortunately, right now I have a very low band connection. Downloading the VM would take more than 3 days according to my browser... Is there another way to test in a "standard" Win10 VM (I've managed to build a standard win10 VM)?

[imaandrew]

You can test it by enabling WSL in the VM. If the VM is running on Hyper-V, you can use WSL2 by running this command in an elevated powershell window: Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true. If it is not running on Hyper-V, you can just use WSL1.

[Trophime]

I finally manage to get it to work ;)) I changed the name of the install.tar.gz to mydistro-install.tar.gz. Once the solution is deployed to test and debug it, I still had to copy the mydistro-install.tar.gz into $ARCH/Debug.

@rhaist I still have a question for you about MyLinuxDistroLauncher.cpp into the salsa WSL. this->_myName= L"Debian"; corresponds to const std::wstring Name = L"MyDistribution"; in Distribution.h right? Why do you introduce this MyLinuxDistroLauncher.cpp for?

Next how can I actually package mydistro to distribute on an other machine?

Many thanks for your helps and tips. Best

[imaandrew]

There is a guide for packaging your distro here.

[steeleprice]

The Readme.md does not reflect ANY of this and is exceedingly difficult to follow even for seasoned Microsoft Stack developers let alone Linux Devs.

The above referenced "guide" is an early preview and is outdated, nothing looks like those screenshots anymore.

It is expected that you understand how to setup a Visual Studio Environment (which most who care about this won't). And how to setup Windows 10 "correctly" as both an x64 and ARM64 Developer. These are very poor assumptions when your audience is a foreign dev community.

This is NON-Trivial to setup as an ARM64 Developer, even for side-loading, especially in a Domain where you may have to override Group Policies. I'll be writing up several issues that arise out of this project and solutions to all of them.

I have a working x64 Distro not represented and will be submitting it to the store after permission is granted from the Distro in a few days and I fix/finish the ARM64 release.

There are also some considerations that should be updated for WSL2 such as Kernel replacement. Should WSL2/VS2019+ Instructions be a different Branch? This is still valid for Win10 19.09 but changes a little in 20.04.

[rescenic]

Please, we need youtube tutorial, thanks.