-1

I'm trying to build an Image using Yocto Project. I need to build it for the future entirely offline. I generated the tarballs once online and moved them to my local mirror source directory. Then, I deleted all my build directory but the conf directory, added BB_NO_NETWORK = "1" and disabled the resolution names from my machine. So far so good, bitbake is fetching all from my local mirror and building the recipes.

My problem is that I have a recipe that tries to get a file in do_compile time. I get an error because the name couldn't be resolved. The recipe is the telegraf one, the error is:

ERROR: telegraf-1.14.5-r0 do_compile: Execution of '...../telegraf/1.14.5-r0/temp/run.do_compile.787' failed with exit code 1:
go: cloud.google.com/go@v0.53.0: Get "https://proxy.golang.org/cloud.google.com/go/@v/v0.53.0.mod": dial tcp: lookup proxy.golang.org on [::1]:53: read udp [::1]:36724->[::1]:53: read: connection refused

When I generate the image when my machine is online, the error doesn't happen and I can find that .mod file inside a cache directory, so I could store that file in my mirror directory and set in the recipe the location of it, instead of that URL, but I don't know how to do this. It appears that mirror only works in do_fetch.

I tried to search in my source files for that URL, but I couldn't find it.

Can anyone help me?

Jonathan Hall
  • 75,165
  • 16
  • 143
  • 189
Gustavo Nóbrega
  • 49
  • 4

2 Answers2

3

I have no idea what yocto, bitbake and the rest of the tags you added are, but the error appears to clearly be from a call to go build or go install on a project which contains a go.mod file which lists a set of external dependencies for the project to be built.
These deps are attempted to be fetched (into a local cache) to be then built and used to build the target package.

There are multiple ways to solve this:

  • Vendor all the dependencies:

    Go to the project which causes this and run go mod vendor — a subdirectory called "vendor" will be created, containing the source code of the dependent packages.

    You can then add this directory and commit the change.

    The next time you run go {build|install} at that project's directory, the presence of the "vendor" directory will force the Go toolchain to first consider its content to satisfy the dependencies.

  • Maintain the deps externally, unvendored.

    The go.mod file supports the replace directive which allows to tell which URL or local directory contain the code of the dependency.

    Hence you can obtain all these deps (say, with go mod download -x; notice the -x — it will tell you the pathnames of the ZIP archive files containing the fetched modules placed in the local cache) then unwrap them somewhere and place the appropriate redirects in the go.mod file.

  • Keep a local cache with the deps

    The go toolchain consults the GOCACHE environment variable when operating on the deps.

    So you can set up a cache directory somewhere in your project, export GOCACHE pointing at it, run go mod download, add and commit the cache.

    You then modify the project's build scripts to properly set this env. variable before calling go, and also make sure to export GOPRIVATE=* to make the toolchain consider all modules as "private" and hence to do no inquiries about them via the network.

I'd go with vendoring but you might do some research and pick what suits you best.

Please make sure you're using Go ≥ 1.14.

kostix
  • 51,517
  • 14
  • 93
  • 176
0

I just searched and found a new version of the telegraf recipe. I changed to it and the problem was solved.

Gustavo Nóbrega
  • 49
  • 4