Re: [OE-core] Status of Go support

[Robert Berger]

Hi,

My comments are in-line.

On 23/06/2020 19:37, Stefan Herbrechtsmeier wrote:

Hi,

because of the changes to the 'GO111MODULE' variable in go-dep and 
glide, I wonder if Go is ready for use. I would have expected the 
variable GO111MODULE to be set to 'off' within the go.bbclass because go 
could bypass the fetch task unobserved otherwise.


Well I guess it depends with what you mean by "ready to use".

I tried it a couple of years ago and now again.

Do you want to build an SDK with the YP and include Golang support?
As far as I saw this kind of works.

Do you want to write a recipe for a non trivial project?

That's fun!

I tried to build from sources telegraf, influxdb and grafana and it's 
great fun for various reasons, among others things depenencies to rust 
and yarn.


I somewhat managed to get influxdb 1.8.0 to compile from sources, but 
only with some hacks and by including some dependencies explicitly, 
which should not need to be included explicitly.


Having said that - I am not a Golang person, so correct me if I'm wrong[1].

[1] 
https://gitlab.com/meta-layers/meta-tig/-/blob/master/recipes-from-source/github.com-influxdata-influxdb/github.com-influxdata-influxdb_1.8.0.bb


... most recipes you find out there in the wild just include prebuilt 
binaries...


There are also quite a few problems with reproduce ability and licensing 
depending on how you write your recipe.


In my recipe I only use the top level license, which is apparently 
wrong. In prebuilt packages it's not much better with licensing.




Regards
   Stefan


Regards,

Robert



-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#140073): 
https://lists.openembedded.org/g/openembedded-core/message/140073
Mute This Topic: https://lists.openembedded.org/mt/75063635/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] Status of Go support

[Stefan Herbrechtsmeier]

Am 25.06.20 um 20:43 schrieb Paul Barker:

On Thu, 25 Jun 2020 at 16:36, Stefan Herbrechtsmeier
 wrote:


Am 24.06.20 um 22:24 schrieb Otavio Salvador:

Em qua., 24 de jun. de 2020 às 17:17, Stefan Herbrechtsmeier
 escreveu:

The go-mod.bbclass download data from the internet during do_compile. If
you cut the internet connection after a do_fetch the do_compile failed:


Yes, this was the better we could get without hacking go mod tool
itself. It would be nice if you can provide an alternative way to
improve it.



What are the alternative?

a) Add a fetcher to bitbake to create a vendor directory via `go mod
vendor`?
b) Add a `create_go.py` to recipetool and create a recipe per module?

The solutions are related to the npm (a) and python (b) solution.

I don't like a) because it breaks the best practices of OE (for example
one major version per project and avoid embedded dependencies). On the
other side b) isn't so simple because of the circular dependency between
go projects. This means we need a package (recipe) for the source and
the binary.


(a) may not be in line with past best practices but I think it's
better than no change. It at least gives the archiver and licensing
classes a chance to capture the relevant artifacts (if configured
correctly) and so do proper license compliance and/or maintain a
source mirror.

I think the Python method of one recipe per dependency works well for
Python since it's not common to distribute a built artifact which
statically links all those dependencies together. That's often not the
case with rust and golang projects though.


The advantage of go-mod and cargo in compare to npm is that they enforce 
semver. This mean you could provide one recipe per major version. The 
statically linked dependencies are more a size problem on the target.



I still think one recipe
per upstream project with dependencies fully expressed in the bitbake
recipes would be ideal but as others have said that's fighting a
losing battle.


The main problem is that this package manager work different from the oe 
approach. This package managers collect all dependencies at once and 
doesn't process package after package.


I try to create one recipe per module (project) but have the problem 
that two project depend on each other.




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139968): 
https://lists.openembedded.org/g/openembedded-core/message/139968
Mute This Topic: https://lists.openembedded.org/mt/75063635/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] Status of Go support

[Stefan Herbrechtsmeier]

Am 25.06.20 um 20:40 schrieb Otavio Salvador:

Em qui., 25 de jun. de 2020 às 15:35, Stefan Herbrechtsmeier
 escreveu:


Am 25.06.20 um 18:43 schrieb Otavio Salvador:

Offline build, using go mod, I can only envision if we somehow provide
a local server which uses the bitbake cache as source. This by itself
is not a small project.


What do you mean by 'provide a local server'? Do you mean a registry
server for go-mod and cargo?


Yes, this is how imagine it'd work for long term and with a more
maintainable way. That said, it is not a small project, for sure.


But this means you have to provide a specific serer for every package 
manager.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139966): 
https://lists.openembedded.org/g/openembedded-core/message/139966
Mute This Topic: https://lists.openembedded.org/mt/75063635/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] Status of Go support

[Paul Barker]

On Thu, 25 Jun 2020 at 16:36, Stefan Herbrechtsmeier
 wrote:
>
> Am 24.06.20 um 22:24 schrieb Otavio Salvador:
> > Em qua., 24 de jun. de 2020 às 17:17, Stefan Herbrechtsmeier
> >  escreveu:
> >> The go-mod.bbclass download data from the internet during do_compile. If
> >> you cut the internet connection after a do_fetch the do_compile failed:
> >
> > Yes, this was the better we could get without hacking go mod tool
> > itself. It would be nice if you can provide an alternative way to
> > improve it.
> >
>
> What are the alternative?
>
> a) Add a fetcher to bitbake to create a vendor directory via `go mod
> vendor`?
> b) Add a `create_go.py` to recipetool and create a recipe per module?
>
> The solutions are related to the npm (a) and python (b) solution.
>
> I don't like a) because it breaks the best practices of OE (for example
> one major version per project and avoid embedded dependencies). On the
> other side b) isn't so simple because of the circular dependency between
> go projects. This means we need a package (recipe) for the source and
> the binary.

(a) may not be in line with past best practices but I think it's
better than no change. It at least gives the archiver and licensing
classes a chance to capture the relevant artifacts (if configured
correctly) and so do proper license compliance and/or maintain a
source mirror.

I think the Python method of one recipe per dependency works well for
Python since it's not common to distribute a built artifact which
statically links all those dependencies together. That's often not the
case with rust and golang projects though. I still think one recipe
per upstream project with dependencies fully expressed in the bitbake
recipes would be ideal but as others have said that's fighting a
losing battle.

-- 
Paul Barker
Konsulko Group
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139965): 
https://lists.openembedded.org/g/openembedded-core/message/139965
Mute This Topic: https://lists.openembedded.org/mt/75063635/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] Status of Go support

[Otavio Salvador]

Em qui., 25 de jun. de 2020 às 15:35, Stefan Herbrechtsmeier
 escreveu:
>
> Am 25.06.20 um 18:43 schrieb Otavio Salvador:
> > Offline build, using go mod, I can only envision if we somehow provide
> > a local server which uses the bitbake cache as source. This by itself
> > is not a small project.
>
> What do you mean by 'provide a local server'? Do you mean a registry
> server for go-mod and cargo?

Yes, this is how imagine it'd work for long term and with a more
maintainable way. That said, it is not a small project, for sure.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139964): 
https://lists.openembedded.org/g/openembedded-core/message/139964
Mute This Topic: https://lists.openembedded.org/mt/75063635/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] Status of Go support

[Stefan Herbrechtsmeier]

Am 25.06.20 um 18:43 schrieb Otavio Salvador:

Em qui., 25 de jun. de 2020 às 12:36, Stefan Herbrechtsmeier
 escreveu:

Am 24.06.20 um 22:24 schrieb Otavio Salvador:

Em qua., 24 de jun. de 2020 às 17:17, Stefan Herbrechtsmeier
 escreveu:

The go-mod.bbclass download data from the internet during do_compile. If
you cut the internet connection after a do_fetch the do_compile failed:


Yes, this was the better we could get without hacking go mod tool
itself. It would be nice if you can provide an alternative way to
improve it.



What are the alternative?

a) Add a fetcher to bitbake to create a vendor directory via `go mod
vendor`?
b) Add a `create_go.py` to recipetool and create a recipe per module?

The solutions are related to the npm (a) and python (b) solution.

I don't like a) because it breaks the best practices of OE (for example
one major version per project and avoid embedded dependencies). On the
other side b) isn't so simple because of the circular dependency between
go projects. This means we need a package (recipe) for the source and
the binary.


Honestly, it is hard. It kinda conflicts with the way go mod, cargo,
and similar tools work.


Both tools support a vendor command to download all dependencies. The 
fetcher need to call this command and archive the vendor folder. 
Alternative both tools support a replace / patch instruction to override 
dependencies with local directories.



Offline build, using go mod, I can only envision if we somehow provide
a local server which uses the bitbake cache as source. This by itself
is not a small project.


What do you mean by 'provide a local server'? Do you mean a registry 
server for go-mod and cargo?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139963): 
https://lists.openembedded.org/g/openembedded-core/message/139963
Mute This Topic: https://lists.openembedded.org/mt/75063635/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] Status of Go support

[Khem Raj]

On 6/25/20 9:43 AM, Otavio Salvador wrote:
> Em qui., 25 de jun. de 2020 às 12:36, Stefan Herbrechtsmeier
>  escreveu:
>> Am 24.06.20 um 22:24 schrieb Otavio Salvador:
>>> Em qua., 24 de jun. de 2020 às 17:17, Stefan Herbrechtsmeier
>>>  escreveu:
 The go-mod.bbclass download data from the internet during do_compile. If
 you cut the internet connection after a do_fetch the do_compile failed:
>>>
>>> Yes, this was the better we could get without hacking go mod tool
>>> itself. It would be nice if you can provide an alternative way to
>>> improve it.
>>>
>>
>> What are the alternative?
>>
>> a) Add a fetcher to bitbake to create a vendor directory via `go mod
>> vendor`?
>> b) Add a `create_go.py` to recipetool and create a recipe per module?
>>
>> The solutions are related to the npm (a) and python (b) solution.
>>
>> I don't like a) because it breaks the best practices of OE (for example
>> one major version per project and avoid embedded dependencies). On the
>> other side b) isn't so simple because of the circular dependency between
>> go projects. This means we need a package (recipe) for the source and
>> the binary.
> 
> Honestly, it is hard. It kinda conflicts with the way go mod, cargo,
> and similar tools work.
> 
> Offline build, using go mod, I can only envision if we somehow provide
> a local server which uses the bitbake cache as source. This by itself
> is not a small project.
> 

I agree, its a losing battle
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139961): 
https://lists.openembedded.org/g/openembedded-core/message/139961
Mute This Topic: https://lists.openembedded.org/mt/75063635/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] Status of Go support

[Otavio Salvador]

Em qui., 25 de jun. de 2020 às 12:36, Stefan Herbrechtsmeier
 escreveu:
> Am 24.06.20 um 22:24 schrieb Otavio Salvador:
> > Em qua., 24 de jun. de 2020 às 17:17, Stefan Herbrechtsmeier
> >  escreveu:
> >> The go-mod.bbclass download data from the internet during do_compile. If
> >> you cut the internet connection after a do_fetch the do_compile failed:
> >
> > Yes, this was the better we could get without hacking go mod tool
> > itself. It would be nice if you can provide an alternative way to
> > improve it.
> >
>
> What are the alternative?
>
> a) Add a fetcher to bitbake to create a vendor directory via `go mod
> vendor`?
> b) Add a `create_go.py` to recipetool and create a recipe per module?
>
> The solutions are related to the npm (a) and python (b) solution.
>
> I don't like a) because it breaks the best practices of OE (for example
> one major version per project and avoid embedded dependencies). On the
> other side b) isn't so simple because of the circular dependency between
> go projects. This means we need a package (recipe) for the source and
> the binary.

Honestly, it is hard. It kinda conflicts with the way go mod, cargo,
and similar tools work.

Offline build, using go mod, I can only envision if we somehow provide
a local server which uses the bitbake cache as source. This by itself
is not a small project.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139960): 
https://lists.openembedded.org/g/openembedded-core/message/139960
Mute This Topic: https://lists.openembedded.org/mt/75063635/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] Status of Go support

[Stefan Herbrechtsmeier]

Am 24.06.20 um 22:24 schrieb Otavio Salvador:

Em qua., 24 de jun. de 2020 às 17:17, Stefan Herbrechtsmeier
 escreveu:

The go-mod.bbclass download data from the internet during do_compile. If
you cut the internet connection after a do_fetch the do_compile failed:


Yes, this was the better we could get without hacking go mod tool
itself. It would be nice if you can provide an alternative way to
improve it.



What are the alternative?

a) Add a fetcher to bitbake to create a vendor directory via `go mod 
vendor`?

b) Add a `create_go.py` to recipetool and create a recipe per module?

The solutions are related to the npm (a) and python (b) solution.

I don't like a) because it breaks the best practices of OE (for example 
one major version per project and avoid embedded dependencies). On the 
other side b) isn't so simple because of the circular dependency between 
go projects. This means we need a package (recipe) for the source and 
the binary.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139955): 
https://lists.openembedded.org/g/openembedded-core/message/139955
Mute This Topic: https://lists.openembedded.org/mt/75063635/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] Status of Go support

[Otavio Salvador]

Em qua., 24 de jun. de 2020 às 17:17, Stefan Herbrechtsmeier
 escreveu:
> The go-mod.bbclass download data from the internet during do_compile. If
> you cut the internet connection after a do_fetch the do_compile failed:

Yes, this was the better we could get without hacking go mod tool
itself. It would be nice if you can provide an alternative way to
improve it.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139900): 
https://lists.openembedded.org/g/openembedded-core/message/139900
Mute This Topic: https://lists.openembedded.org/mt/75063635/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] Status of Go support

[Stefan Herbrechtsmeier]

Am 23.06.20 um 21:56 schrieb Khem Raj:

On 6/23/20 11:35 AM, Stefan Herbrechtsmeier wrote:

Am 23.06.20 um 20:16 schrieb Khem Raj:
On Tue, Jun 23, 2020 at 9:47 AM Otavio Salvador 
> wrote:


    Hello Stefan,

    Em ter., 23 de jun. de 2020 às 13:37, Stefan Herbrechtsmeier
    mailto:ste...@herbrechtsmeier.net>>
    escreveu:
 > because of the changes to the 'GO111MODULE' variable in go-dep 
and

 > glide, I wonder if Go is ready for use. I would have expected the
 > variable GO111MODULE to be set to 'off' within the go.bbclass
    because go
 > could bypass the fetch task unobserved otherwise.

    Is there any known issue?

    For me, with those fixes, it is working fine.


Yes it’s working ok with go-module for me but not sure of go-dep has 
regresse


What is the expected behavior of go-module and go-dep? Does they work 
without network connection after a bitbake -c fetch?


I think so. Its perhaps after first build unless you clean the build tree.


The go-mod.bbclass download data from the internet during do_compile. If 
you cut the internet connection after a do_fetch the do_compile failed:


| DEBUG: Executing shell function do_compile
| go: github.com/nats-io/jwt@v0.3.2: Get 
"https://proxy.golang.org/github.com/nats-io/jwt/@v/v0.3.2.mod": dial 
tcp: lookup proxy.golang.org on 127.0.0.53:53: server misbehaving
| go: github.com/nats-io/jwt@v0.3.2: Get 
"https://proxy.golang.org/github.com/nats-io/jwt/@v/v0.3.2.mod": dial 
tcp: lookup proxy.golang.org on 127.0.0.53:53: server misbehaving




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139899): 
https://lists.openembedded.org/g/openembedded-core/message/139899
Mute This Topic: https://lists.openembedded.org/mt/75063635/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] Status of Go support

[Khem Raj]

On 6/23/20 11:35 AM, Stefan Herbrechtsmeier wrote:

Hi,

Am 23.06.20 um 20:16 schrieb Khem Raj:
On Tue, Jun 23, 2020 at 9:47 AM Otavio Salvador 
> wrote:


    Hello Stefan,

    Em ter., 23 de jun. de 2020 às 13:37, Stefan Herbrechtsmeier
    mailto:ste...@herbrechtsmeier.net>>
    escreveu:
 > because of the changes to the 'GO111MODULE' variable in go-dep and
 > glide, I wonder if Go is ready for use. I would have expected the
 > variable GO111MODULE to be set to 'off' within the go.bbclass
    because go
 > could bypass the fetch task unobserved otherwise.

    Is there any known issue?

    For me, with those fixes, it is working fine.


Yes it’s working ok with go-module for me but not sure of go-dep has 
regresse


What is the expected behavior of go-module and go-dep? Does they work 
without network connection after a bitbake -c fetch?


I think so. Its perhaps after first build unless you clean the build tree.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139849): 
https://lists.openembedded.org/g/openembedded-core/message/139849
Mute This Topic: https://lists.openembedded.org/mt/75063635/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] Status of Go support

[Stefan Herbrechtsmeier]

Hi,

Am 23.06.20 um 20:16 schrieb Khem Raj:
On Tue, Jun 23, 2020 at 9:47 AM Otavio Salvador 
> wrote:


Hello Stefan,

Em ter., 23 de jun. de 2020 às 13:37, Stefan Herbrechtsmeier
mailto:ste...@herbrechtsmeier.net>>
escreveu:
 > because of the changes to the 'GO111MODULE' variable in go-dep and
 > glide, I wonder if Go is ready for use. I would have expected the
 > variable GO111MODULE to be set to 'off' within the go.bbclass
because go
 > could bypass the fetch task unobserved otherwise.

Is there any known issue?

For me, with those fixes, it is working fine.


Yes it’s working ok with go-module for me but not sure of go-dep has 
regresse


What is the expected behavior of go-module and go-dep? Does they work 
without network connection after a bitbake -c fetch?
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139845): 
https://lists.openembedded.org/g/openembedded-core/message/139845
Mute This Topic: https://lists.openembedded.org/mt/75063635/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] Status of Go support

[Khem Raj]

On Tue, Jun 23, 2020 at 9:47 AM Otavio Salvador <
otavio.salva...@ossystems.com.br> wrote:

> Hello Stefan,
>
> Em ter., 23 de jun. de 2020 às 13:37, Stefan Herbrechtsmeier
>  escreveu:
> > because of the changes to the 'GO111MODULE' variable in go-dep and
> > glide, I wonder if Go is ready for use. I would have expected the
> > variable GO111MODULE to be set to 'off' within the go.bbclass because go
> > could bypass the fetch task unobserved otherwise.
>
> Is there any known issue?
>
> For me, with those fixes, it is working fine.


Yes it’s working ok with go-module for me but not sure of go-dep has
regressed


>
> --
> Otavio Salvador O.S. Systems
> http://www.ossystems.com.brhttp://code.ossystems.com.br
> Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139844): 
https://lists.openembedded.org/g/openembedded-core/message/139844
Mute This Topic: https://lists.openembedded.org/mt/75063635/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] Status of Go support

[Otavio Salvador]

Hello Stefan,

Em ter., 23 de jun. de 2020 às 13:37, Stefan Herbrechtsmeier
 escreveu:
> because of the changes to the 'GO111MODULE' variable in go-dep and
> glide, I wonder if Go is ready for use. I would have expected the
> variable GO111MODULE to be set to 'off' within the go.bbclass because go
> could bypass the fetch task unobserved otherwise.

Is there any known issue?

For me, with those fixes, it is working fine.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#139843): 
https://lists.openembedded.org/g/openembedded-core/message/139843
Mute This Topic: https://lists.openembedded.org/mt/75063635/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-