• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 453 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

offline yocto build including go package (websocketd)

j j
Prodigy 165 points
Part Number: PROCESSOR-SDK-AM65X

I've followed instructions for processor SDK to pre-download all sources and that works well when transferred to an offline environment for most packages. However, it seems golang packages such as 'websocketd' try to download sources and make https requests to proxy.golang.org/.../v1.4.0.mod and github as part of  the 'do_compile' step.

There are plenty of instructions directing to properly getting bitbake and golang to use http(s) corporate proxies, but how can a completely offline (no access to internet either directly and no proxy) compilation be achieved?

  • 0
    TI__Guru 69807 points

    Hi JJ,

    j j said:
    but how can a completely offline (no access to internet either directly and no proxy) compilation be achieved?

    That's a good question. I think it is very unfortunate that those recipes behave like they do But some ideas....

    1) Setup an internal server/mirror for those external components that get fetched during 'do_compile'. This would allow you to modify/re-build the code.

    2) Store the 'sstate cache' folder as part of your archives. Assuming you are not modifying those recipes, and use the same build environment (compiler, path names, etc.), the 'do_compile' step will actually not get executed but instead Bitbake will just grab the artifacts from the shared state cache and go to the next steps, hence avoiding the extra network accesses.

    Regards, Andreas

  • 0 in reply to Andreas Dannenberg
    Prodigy 165 points

    thank you for the reply.

    1) since the recipe uses httpS, internal mirroring is a bit painful as we would have to deal with creating, trusting, and distributing the certificates

    2) it sounds like this is the only way to go right now.

    Is there any chance that TI would work with the greater yocto community to resolve this in a better way? TI already does a lot of work to mirror the snapshots of the upstream sources for the rest of the SDK to make customer builds more reproducible and dependable, but this golang package (and perhaps others) completely subvert those efforts.

  • 0 in reply to j j
    TI__Guru 69807 points

    Hi jj,

    j j said:
    Is there any chance that TI would work with the greater yocto community to resolve this in a better way? TI already does a lot of work to mirror the snapshots of the upstream sources for the rest of the SDK to make customer builds more reproducible and dependable, but this golang package (and perhaps others) completely subvert those efforts.

    Completely understand your request. I can't make any commitments here but what I can do is file an internal ticket for our R&D team to give this some consideration. Like with everything else there's a prioritization/urgency process involved. But I think this is certainly something we should consider for the reasons you outlined.

    Regards, Andreas