00:00 <abliss> with messages like `go: finding module for package gvisor.dev/gvisor/pkg/sentry/arch/registers_go_proto ../../tools/go/pkg/mod/gvisor.dev/gvisor@v0.0.0-20200527224730-26bbecf00f51/pkg/eventchannel/event.go:29:2: module gvisor.dev/gvisor@latest found (v0.0.0-20200527224\730-26bbecf00f51), but does not contain package gvisor.dev/gvisor/pkg/eventchannel/eventchannel_go_proto`

00:00 <isd> Ah, yeah, if you're not using their bazel build you'll probably have to invoke protoc yourself.

00:01 <abliss> i've checked out the 'go' branch which supposedly works with go tooling instead of bazel

00:04 <isd> Is the stuff in your repo still representative of the build?

00:05 <abliss> no, i haven't pushed anything that actually uses the gvisor code yet, because i haven't been able to get it to work

00:06 <isd> I would do a go mod init github.com/abliss/upty and then add a replace directive.

00:06 <abliss> if i go into the gvisor code, i can build the parts i want with `go build ./pkg/sentry/fsimpl/devpts`

00:07 <abliss> but after doing that go mod init in the outer directory, `go mod vendor` dies because of missing protobuf stuff, and everything else dies telling me to run `go mod vendor`

00:07 <isd> It would be helpful to see what your current tree looks like. Can you push the broken stuff to a branch so I can see it?

00:08 <abliss> pushed to branch gohack

00:12 <isd> Also, you could cut out a lot of the boilerplate by using net.Pipe() and io.Copy() instead of your custom relay* functions.

00:12 <abliss> oh yeah those are just stubs that will go away, don't worry

00:13 <abliss> i tried adding a replace stanza to go.mod. now, `go mod vendor` deletes the vendored code (?!) and then complains that it's missing.

00:14 <abliss> ah, i guess the trick is to not manually populate vendor/ but rather let `go mod vendor` do it. wish the docs had told me that.

00:16 <abliss> ok, it works now, you can stop looking at my ugly hacks :)

00:18 <isd> You can also just update the commit & timestamp in the require clause and get rid of vendor/ entirely.

00:19 <abliss> yeah, i was just trying that. seems to work. thanks.

00:19 <isd> no problem

15:57 <xet7> abliss: Are you a Go programmer? Can you submit pull request that makes this code to build correctly? https://github.com/kanlab/kanlab

15:57 <xet7> abliss: I tried to make it build, but failed

15:59 <xet7> I'm just thinking, is coding with Go even possible? My Go code usually just crashes and I can't get those working.

15:59 <abliss> i'm not really. i was kinda able to build stuff back in the 1.0 days, but i don't understand any of the new module stuff. Ian Denhardt seems much more capable. what error are you seeing?

15:59 <xet7> That's why I think Meteor is best think in the world since sliced bread :D

16:00 <xet7> It was maybe about paths or other dependencies

16:23 <abliss> ugh, i really dislike docker-only-build projects...

16:25 <abliss> trying to hcak a build outside docker, and it complains about a cyclic import (kanban -> cmd -> kanban)

16:25 <abliss> s/kanban/kanlab/g

19:26 <isd> xet7: what's the failure you're seeing now?

19:31 <xet7> isd: I'll try building it to see it. I'll also check has there been any fixes to the upstream project that was already broken.

20:11 <isd> Observation: there's a go.mod file in the repo, but the Makefile is invoking an ancient version of go that predates go modules.

20:20 <xet7> Here someone says they fixed everything in their fork https://gitlab.com/leanlabsio/kanban/-/issues/261#note_228872668

20:20 <xet7> I'm trying to get it built

20:30 <xet7> Wow. I typed "make build" and then "go build" and there is executeable with name "kanban" that seems to show CLI options :D