[go-nuts] Re: go mod download fails on docker for 1.20 (but not for 1.18)

['TheDiveO' via golang-nuts]

carrier-grade NAT?

On Friday, February 2, 2024 at 7:05:42 PM UTC+1 sprynger wrote:

> In my case it might be an ISP problem, since this only happens to me when 
> I work from home. At work, the exact same project builds all at once 
> without any issues.
>
> A quinta-feira, 1 de fevereiro de 2024 à(s) 21:07:03 UTC, TheDiveO 
> escreveu:
>
>> Are you still using Debian 11 and the outdated Debian docker.io package 
>> with Docker 18? What happens when you use a recent Docker, either 24.x or 
>> hot-off-the-press 25.0.1? And then build using a Go-Alpine base image? Do 
>> you still use Debian's broken Docker seccomp profile...?
>>
>> I'm on an IPv6 uplink and in all these years never seen this issue. I'm 
>> not using Debian due to its totally outdated cloud/container packages, but 
>> instead a *ubuntu host with docker-ce packages, using alpine base images 
>> for building ... and never such an issue. So my bet would be on Debian 
>> and/or your ISP. From my bad experience with many nightmarish late hour 
>> diagnosis sessions with oversees my bet is on Debian, especially the LTS 
>> long-term-broken variants.
>>
>> On Thursday, February 1, 2024 at 8:48:42 PM UTC+1 Sebastiaan van der 
>> Meulen wrote:
>>
>>> Same issue here without solution. Hoping anyone finds one
>>>
>>> Op zondag 14 januari 2024 om 22:53:54 UTC+1 schreef Dmitry Anderson 
>>> (4nd3rs0n):
>>>
 I'm having the same problem. For now I just vendor modules to a project 
 modules and run without installing anything from the container, but also 
 would like to find a fix.
 On Monday, May 22, 2023 at 2:29:08 AM UTC+2 Joao Miguel Ferreira wrote:

> Hello all,
>
> My docker build is ok with FROM golang:1.18-alpine, FROM 
> golang:1.18-buster and FROM golang:1.18-bullseye images. The 
> application works. All is fine on the 3 cases.
>
> But the docker build fails with FROM golang:1.20-alpine, FROM 
> golang:1.20-buster and FROM golang:1.20-bullseye images.
>
> This is the error message I get:
>
> go: github.com/davecgh/go-...@v1.1.1 
> : Get "
> https://proxy.golang.org/github.com/davecgh/go-spew/@v/v1.1.1.mod": 
> dial tcp [2a00:1450:4003:801::2011]:443: connect: cannot assign requested 
> address
>
> It happens during go mod download. It happens when building on 
> Debian11, Debian12 and Ubuntu22 hosts.
>
> I have tried many things including going inside the container and 
> downloading the module with wget. It works fine. Maybe something changed 
> from 1.18 to 1.20 related to ipv6.
>
> I would like to be able to do the build with one golang 1.20 image. 
> But I can not understand what is wrong. Can you help clarify that error 
> and 
> how to overcome it?
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7f892f6a-50bc-4b4b-9679-3cab77693152n%40googlegroups.com.

Re: [go-nuts] Is this runtime.KeepAlive call really necessary

[Ian Lance Taylor]

On Fri, Feb 2, 2024 at 10:05 AM Chong Yuan  wrote:
>
> Here is the example in our gorocksdb:
>
> // Get returns the data associated with the key from the database.
>
> func (db *DB) Get(opts *ReadOptions, key []byte) (*Slice, error) {
>
>var (
>
>   cErr*C.char
>
>   cValLen C.size_t
>
>   cKey= byteToChar(key)
>
>)
>
>cValue := C.rocksdb_get(db.c, opts.c, cKey, 
> C.size_t(len(key)), , )
>
>runtime.KeepAlive(key)  //<==this is the customization we 
> added.
>
>if cErr != nil {
>
>   defer C.rocksdb_free(unsafe.Pointer(cErr))
>
>   return nil, errors.New(C.GoString(cErr))
>
>}
>
>return NewSlice(cValue, cValLen), nil
>
> }
>
> // byteToChar returns *C.char from byte slice.
>
> func byteToChar(b []byte) *C.char {
>
>var c *C.char
>
>if len(b) > 0 {
>
>   c = (*C.char)(unsafe.Pointer([0]))
>
>}
>
>return c
>
> }
>
> My question is: if the keepalive(key) is necessary above. Will the "key" be 
> GC-ed when calling into C.rocksdb_get(). Does the compiler know there’s a 
> reference to “key” (using unsafe.pointer) and not collect “key” when running 
> GC?

That call to runtime.KeepAlive does not look necessary.  Pointers
passed to cgo functions are kept alive for the duration of the call.
The pointer returned by byteToChar will keep the slice's backing array
alive.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWv-JY_iA-TQW3Vvob-T9wmPxHW5fFPrreBJdvG-z%3D7YA%40mail.gmail.com.

Re: [go-nuts] Printf

[Luca Pascali]

you forgot the \n in the printf format string

without it, next is written right after the end of the printf


Psk

Il ven 2 feb 2024, 17:56 Juan Mamani  ha
scritto:

> Hi everybody!
>
> I was checking consistency  behavior of fmt.Printf with some basic
> samples. And for my surprise never expected what I found.
>
> My context:
> OS: Linux, debian 8,9,10,11
> Go version 1.21
>
> What I was doing? Learning about fmt.Printf
> Expecting fmt.Printf behavior be the same output for any use case.
>
> Source code: https://go.dev/play/p/oKifC9Lw-JO
>
>
> Ouput:
> g_x 15.9259995
> 15.91.6241.624<- for me this is freaking weird ouput
> --
> x2: 1.624
> x2: 1.624
> x1: 15.9259996
> --
> j: 4
> k: 5
> p: 1.624
>
> May be I found compiler bug?  Can someone help me to figure out what is
> going on.
>
> Thank you for your attention
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/0b8e4c5a-ceef-49e8-8546-bcd51200ff35n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAJNBTxL7zHtvtoms0kMuq9WTrffxJ_YyxCd-5Or%2Bv2YGbu2PeA%40mail.gmail.com.

[go-nuts] Is this runtime.KeepAlive call really necessary

[Chong Yuan]

Here is the example in our gorocksdb:

// Get returns the data associated with the key from the database.

func (db *DB) Get(opts *ReadOptions, key []byte) (*Slice, error) {

   var (

  cErr*C.char

  cValLen C.size_t

  cKey= byteToChar(key)

   )

   cValue := C.rocksdb_get(db.c, opts.c, cKey, 
C.size_t(len(key)), , )

   runtime.KeepAlive(key)  //<==this is the customization we 
added.

   if cErr != nil {

  defer C.rocksdb_free(unsafe.Pointer(cErr))

  return nil, errors.New(C.GoString(cErr))

   }

   return NewSlice(cValue, cValLen), nil

}

// byteToChar returns *C.char from byte slice.

func byteToChar(b []byte) *C.char {

   var c *C.char

   if len(b) > 0 {

  c = (*C.char)(unsafe.Pointer([0]))

   }

   return c

}
My question is: if the keepalive(key) is necessary above. Will the "key" be 
GC-ed when calling into C.rocksdb_get(). Does the compiler know there’s a 
reference to “key” (using unsafe.pointer) and not collect “key” when 
running GC?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a03805af-511d-400f-88b3-02e1501e3211n%40googlegroups.com.

[go-nuts] Re: go mod download fails on docker for 1.20 (but not for 1.18)

[sprynger]

In my case it might be an ISP problem, since this only happens to me when I 
work from home. At work, the exact same project builds all at once without 
any issues.

A quinta-feira, 1 de fevereiro de 2024 à(s) 21:07:03 UTC, TheDiveO escreveu:

> Are you still using Debian 11 and the outdated Debian docker.io package 
> with Docker 18? What happens when you use a recent Docker, either 24.x or 
> hot-off-the-press 25.0.1? And then build using a Go-Alpine base image? Do 
> you still use Debian's broken Docker seccomp profile...?
>
> I'm on an IPv6 uplink and in all these years never seen this issue. I'm 
> not using Debian due to its totally outdated cloud/container packages, but 
> instead a *ubuntu host with docker-ce packages, using alpine base images 
> for building ... and never such an issue. So my bet would be on Debian 
> and/or your ISP. From my bad experience with many nightmarish late hour 
> diagnosis sessions with oversees my bet is on Debian, especially the LTS 
> long-term-broken variants.
>
> On Thursday, February 1, 2024 at 8:48:42 PM UTC+1 Sebastiaan van der 
> Meulen wrote:
>
>> Same issue here without solution. Hoping anyone finds one
>>
>> Op zondag 14 januari 2024 om 22:53:54 UTC+1 schreef Dmitry Anderson 
>> (4nd3rs0n):
>>
>>> I'm having the same problem. For now I just vendor modules to a project 
>>> modules and run without installing anything from the container, but also 
>>> would like to find a fix.
>>> On Monday, May 22, 2023 at 2:29:08 AM UTC+2 Joao Miguel Ferreira wrote:
>>>
 Hello all,

 My docker build is ok with FROM golang:1.18-alpine, FROM 
 golang:1.18-buster and FROM golang:1.18-bullseye images. The 
 application works. All is fine on the 3 cases.

 But the docker build fails with FROM golang:1.20-alpine, FROM 
 golang:1.20-buster and FROM golang:1.20-bullseye images.

 This is the error message I get:

 go: github.com/davecgh/go-...@v1.1.1 
 : Get "
 https://proxy.golang.org/github.com/davecgh/go-spew/@v/v1.1.1.mod": 
 dial tcp [2a00:1450:4003:801::2011]:443: connect: cannot assign requested 
 address

 It happens during go mod download. It happens when building on 
 Debian11, Debian12 and Ubuntu22 hosts.

 I have tried many things including going inside the container and 
 downloading the module with wget. It works fine. Maybe something changed 
 from 1.18 to 1.20 related to ipv6.

 I would like to be able to do the build with one golang 1.20 image. But 
 I can not understand what is wrong. Can you help clarify that error and 
 how 
 to overcome it?




-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/955cbf54-2d22-4e29-8f0d-778d2471fe68n%40googlegroups.com.

Re: [go-nuts] Printf

[Kurtis Rader]

I think you're being confused by the lack of newlines in the output. Add
"\n" to the end of the printf format.

On Fri, Feb 2, 2024 at 8:56 AM Juan Mamani 
wrote:

> Hi everybody!
>
> I was checking consistency  behavior of fmt.Printf with some basic
> samples. And for my surprise never expected what I found.
>
> My context:
> OS: Linux, debian 8,9,10,11
> Go version 1.21
>
> What I was doing? Learning about fmt.Printf
> Expecting fmt.Printf behavior be the same output for any use case.
>
> Source code: https://go.dev/play/p/oKifC9Lw-JO
>
>
> Ouput:
> g_x 15.9259995
> 15.91.6241.624<- for me this is freaking weird ouput
> --
> x2: 1.624
> x2: 1.624
> x1: 15.9259996
> --
> j: 4
> k: 5
> p: 1.624
>
> May be I found compiler bug?  Can someone help me to figure out what is
> going on.
>
> Thank you for your attention
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/0b8e4c5a-ceef-49e8-8546-bcd51200ff35n%40googlegroups.com
> 
> .
>


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD8G933z78RdaWY_yDbiigREvVr5Wv%2BVNy3GycWU%2BynzuQ%40mail.gmail.com.

[go-nuts] morbyd: a thin layer to easily build and run throw-away test containers, etc. in tests

['TheDiveO' via golang-nuts]

https://github.com/thediveo/morbyd is a thin layer on top of the standard 
Docker Go client to easily build and run throw-away test Docker images and 
containers, and running commands inside them. It features a function option 
API to keep the slightly excessive Docker API option parameters at bay. 
(And large test coverage FWIW).

You might ask: why, when there's ory/dockertest/v3?

Because their Ory's proprietary Docker client (predating the canonical one) 
is incompatible with the Docker daemon's 100 CONTINUE header when streaming 
container and command stdout/stderr. I've reported this, but did not got 
any response at all, so I finally cut my losses and wrote "morbyd" to be 
able to move on. The proper Docker client allows me to easily dump and 
analyse build and container output when tests go south.

Below is how morbyd feels, compared to ory/dockertest/v3, to give you an 
idea which API design might be better suited for you (or not):

dockertest (using Gomega for assertions):

Expect(pool.Client.BuildImage(docker.BuildImageOptions{
Name:   img.Name,
ContextDir: "./test/_kindisch", // sorry, couldn't resist the pun.
Dockerfile: "Dockerfile",
BuildArgs: []docker.BuildArg{
{Name: "KINDEST_BASE_TAG", Value: test.KindestBaseImageTag},
},
OutputStream: io.Discard,
})).To(Succeed())
providerCntr := Successful(pool.RunWithOptions(
{
Name:   kindischName,
Repository: img.Name,
Privileged: true,
Mounts: []string{
"/var", // well, this actually is an unnamed volume
"/dev/mapper:/dev/mapper",
"/lib/modules:/lib/modules:ro",
},
Tty: true,
}, func(hc *docker.HostConfig) {
hc.Init = false
hc.Tmpfs = map[string]string{
"/tmp": "",
"/run": "",
}
hc.Devices = []docker.Device{
{PathOnHost: "/dev/fuse"},
}
}))

morbyd (also using Gomega for assertions):

Expect(sess.BuildImage(ctx, "./test/_kindisch",
build.WithTag(img.Name),
build.WithBuildArg("KINDEST_BASE_TAG="+test.KindestBaseImageTag),
build.WithOutput(timestamper.New(GinkgoWriter.
Error().NotTo(HaveOccurred())
providerCntr := Successful(sess.Run(ctx, img.Name,
run.WithName(kindischName),
run.WithAutoRemove(),
run.WithPrivileged(),
run.WithSecurityOpt("label=disable"),
run.WithCgroupnsMode("private"),
run.WithVolume("/var"),
run.WithVolume("/dev/mapper:/dev/mapper"),
run.WithVolume("/lib/modules:/lib/modules:ro"),
run.WithTmpfs("/tmp"),
run.WithTmpfs("/run"),
run.WithDevice("/dev/fuse"),
run.WithCombinedOutput(timestamper.New(GinkgoWriter

Some of these options are not simply writing their arg in the same-name 
struct field, but instead are parsing things, preferably in the same way as 
the Docker CLI does. So the transition from CLI args to unit test args 
should be much smoother without having to dig deep into the Docker API 
parameter details.

While I tried to strive for more option completeness than just my own 
minimal viable proof, there surely a bits and pieces missing. In case 
morbyd might be interesting for you, I would be glad to hear from you and 
also missing pieces; and preferably a PR if you would be so kind.



-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/34643167-7222-4e7a-a1a8-79d757c2c8fen%40googlegroups.com.

[go-nuts] Printf

[Juan Mamani]

Hi everybody!

I was checking consistency  behavior of fmt.Printf with some basic samples. 
And for my surprise never expected what I found.

My context:
OS: Linux, debian 8,9,10,11
Go version 1.21

What I was doing? Learning about fmt.Printf
Expecting fmt.Printf behavior be the same output for any use case.

Source code: https://go.dev/play/p/oKifC9Lw-JO


Ouput:
g_x 15.9259995
15.91.6241.624<- for me this is freaking weird ouput
--
x2: 1.624
x2: 1.624
x1: 15.9259996
--
j: 4
k: 5
p: 1.624

May be I found compiler bug?  Can someone help me to figure out what is 
going on.

Thank you for your attention

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0b8e4c5a-ceef-49e8-8546-bcd51200ff35n%40googlegroups.com.