dotnet restore error NU1301: Unable to load the service index for source https://api.nuget.org/v3/index.json.

[jeikki]

It seems that dotnet_do_configure is unable to reach NuGet repository to restore project dependencies. It is not about the api.nuget.org endpoint since I'm not even able to curl google.com in the dotnet_do_configure function.

Dotnet restore and internet overall works just fine outside of bitbake. Feels like bitbake has somehow restricted internet access in the scope of dotnet_do_configure function. Any ideas?

[jeremy-prater]

That is odd, as far as I know there are no network restrictions in any functions in bitbake. Are you running your yocto build environment in a docker? (I do that because my host is Arch, and I use a ubuntu 20.04 docker image to build in) That wouldn't make sense though because then do_fetch would have also failed. Can you post the entire log.do_configure file from your failed recipe?

[jeikki]

I'm building Yocto natively (without docker) with Debian 11 x64 virtual machine hosted in Azure. I'm following this guide for building Kirkstone Poky for qemux86-64. I got the example recipe working and QEMU running the image.

I created my own layer and recipe to fetch, compile and install my .NET 6 console application binary to the image. I'm using this meta-dotnet layer but needed to make some changes in order to support Kirkstone and also updated the dotnet sdk version to the latest just in case it fixed the problem. I will make a branch of my changes tomorrow for you to review.

Fetching sources from remote git repository goes smoothly but the bitbake fails to do the configuration for the recipe because the dotnet restore fails. I can do the dotnet restore successfully for the same sources fetched by the bitbake with separately installed dotnet sdk. Please see the archived do_configure log attached (log.do_configure.zip).

I also now tried the test recipe of the meta-dotnet with same results. Although now it is the do_compile function that fails. Please see the log.do_compile attached (log.do_compile.zip).

This is indeed a really weird issue. All ideas and suggestions are warmly welcome! I would really like to use this layer in my project and make contributions. Thanks for sharing it!

log.do_compile.zip log.do_configure.zip

[jeikki]

No idea why but inside the docker container (crops/poky:ubuntu-22.04) the dotnet restore works as you said. I don't have any ideas on how to investigate this further. You could maybe try to reproduce the issue without docker to verify it is not just my environment.

[jeremy-prater]

Thanks for the Pull requests! I branched dunfell and then merged your changes in 👍 As for the network issue, I'm not entirely sure why your build environment is doing that. I haven't seen that. I could try and setup an environment similar to yours to reproduce it.

[LoloActemium]

Hello,

Nice job 👍

But, I have the same issue on my environment :). Ubuntu 22.04.1 LTS runing on an ESXi VM. Used latest kirkstone branch for Yocto & Co. I tried to build the sample directly from the cmd line without any problem. It appears only when "bibaking". Did you find anything ? I will continue investigating a bit.

Kind Regards, Laurent.

[angrdtsk]

I am having the same problem.

My build environment is a Docker container based on Ubuntu 20.04, which I run under another Ubuntu 20.04 in a virtual machine using VirtualBox. The actual hardware is running Windows 10.

I can build the hello world program that comes with the layer inside the container manually, using .NET SDK I have installed manually, but when I try the same using bitbake, do_configure for dotnet-hello-world says "error NU1301: Unable to load the service index for source https://api.nuget.org/v3/index.json".

There seems to be a plenty of suggestions for solution available by googling , but they are all for Windows and Visual Studio environment and I have no idea how to try them with Yocto if that's even possible.

[angrdtsk]

Many of the Windows/VS-related suggestion are about modifying or removing nuget.config. I noticed that there is similar looking file in my Yocto tree at build/tmp/work/cortexa72-poky-linux/dotnet-hello-world/1.0-r0/.nuget/NuGet/NuGet.Config.

The original content of that file is this:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
  </packageSources>
</configuration>

I tried replacing it with

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear />
    <add key="NuGet Public" value="https://api.nuget.org/v3/index.json" />
  </packageSources>
</configuration>

but that didn't change anything. My changes remained over the build attempt, though.

I also tried removing that file. That didn't change anything either and the file got restored with the original content during the build.

[angrdtsk]

I did yet some more research.

I tried curl for that url from dotnet-hello-world's do_configure. Using domain name address, it says "Could not resolve host: api.nuget.org" and using numeric address, it says "Couldn't connect to server". They both work when run manually.

I would have tried pinging those addresses from that function too, but I couldn't figure out how to add ping as a host tool.

[jeremy-prater]

I can't really help with these networking issues. I use this meta-layer every day in our build pipelines and it never has an issue connecting to api.nuget.org

[LoloActemium]

Hello,

I also tried a lot of things, but Iwas not able to find a solution, so far. My Yocto build machine is an Ubuntu Server running on a VMWare ESXi. Are you both using virtual machines ?

Laurent

[angrdtsk]

I am out of ideas myself at this point, but I can work on this full-day if anyone comes up with ideas to try, so if you have anything in mind, please share it.

[angrdtsk]

Me and some colleagues found a solution or at least a work-around for this with help of the Yocto mailing list.

Network access from recipes can be controlled using variables do_x[network]. They have been set to 0 for do_configure and do_compile among others and 1 for do_fetch and some others. Setting do_configure[network] and do_compile[network] to 1 in local.conf fixed the issue.

I wonder if the reason that this issue doesn't appear to all people is that people use different versions of Yocto and some older versions don't have those variables or have them set that way.

[LoloActemium]

It works for me too. Thanks to angrdtsk. I created a pull request to add an hint in the Readme file.

[dougcooper]

The solutions in this issue helped immensely, but unrelated to the repo. setting do_configure[network]="1" solved the problem and i recommend closing.