[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

DebConf19 pkg-go BoF minutes (Finally!)



Hi,

here is the long overdue report on the BoF that happened at DebConf19 in Curitiba.

Sorry for the delay, life happened meanwhile and I couldn't find time/energy/motivation for that earlier.

Thanks to everyone who participated in this BoF, helped with taking notes, or even just showed up, 
and special thanks to Tina for participating remotely. :)

I've tried to organize the notes so that there are clear ACTION or DISCUSS items. 
DISCUSS is meant as discuss here on the mailing list. 

Some stuff might be outdated, even though I tried to keep only up to date information… 
Please read and don't hesitate to follow up :)


---

# Minutes of the Debconf19 Go Packaging Team BoF

Go team BoF happened at Debconf19 in Curitiba

## Recording & Gobby notes

There were issues during the recording (no sound at all in the first 3-4
minutes, bad sound until after 00:06:00). The talk recording is still available
at https://debconf19.debconf.org/talks/107-debian-go-packaging-team-bof/

Gobby notes are available on gobby.debian.org - debconf19/bof/pkg-go-bof
As usual, HTML export is at https://gobby.debian.org/export/debconf19/bof/pkg-go-bof

## Roll Call
People present (and willing to add themselves to the list ;) )
- nodens
- zhsj
- Tina
- zigo
- brother
- rajudev
- utkarsh2102
- jmkim

# Topics

## Go library transition and rebuild issue.

We have ignored this, but as we see in the buster freeze phase, the release
team is not happy with this.

### What happened during Buster Freeze:

Some packages where upgraded to a new upstream release in unstable. It is ok
for many cases, but if there are dependancies, it becomes a problem, especially
in our case where we ship statically linked binaries: dependancies of those
packages would be built with the upgraded version… Which violates the Freeze.

Those packages had to be reverted to the testing state with +really versions in
unstable.

DISCUSS: We need to find a way to prevent this to happen. It can start with
policy (e.g. don't upload to unstable during the freeze, use experimental), but
we probably want to go further and manage transitions.

### Rebuild in security archive

Related to the transition issue: maintaining Go packages is a problem for the
Security Team, as any update in a library would mean having to manually handle
all the dependancies (needing a source upload of all those packages to the
Security Archive). That is to much work considering the number of critical Go
packages today (e.g. docker or prometheus).

This should be fixed in bullseye cycle anyway, or the Go stuff will be removed.
See #928026 + 921284

DECISION: nodens will get in touch with someone from the release team to
discuss the dak issue. Further discussion to happen on the Mailing List.
Update post-BoF: nodens talked with Ivod - Detailed email on the issue 

### Migrate away Built-Using, it's now against policy. 

We need to use something different. X-Go-Built-Using comes to mind, as rust
team uses X-Cargo-Built-Using. Since the meaning is the same, it would be nice
to use the same control field but then the name should maybe change ?

Q: How to do it? change all packages' debian/control file?
DISCUSS: first decide on a name, and check if we shouldn't share a name with 
the Rust team since use them in the same way.

## Go mod issue

there is currently a problem to build with go mod. What if GOPATH is deprecated 
by upstream (go1.13 will deprecate GOPATH)?
-  https://blog.golang.org/modules2019
-  https://github.com/golang/go/issues/29410

It should work, and needs change in dh-golang, see last comment by stapelberg in this in the linked issue.

ACTION: check current status

## Cross-Compiling Go packages

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930176 has a patch to allow Cross-Building.

ACTION: review the patch

Update post-BoF: Fixed.

## Breaking loop Build-dependency

Discussion about how to handle circular build-deps.
- #872423 dh-golang: Please build -dev packages only in stage1 to break build-dependency loop

Solution: add stage1 profile. Just copying source files in stage1 and running go {build,install} in stage2

## Workflow Change

Discussion on the updated workflow happened in Debconf17, but it's still not official.
We agree to make it the official policy of the team.

However, there are concerns about needed fixes to documentation and tooling.
 
ACTION: Organize an IRC meeting on the Mailing List to check whatever needs to be improved.
Then, fix go-team.pages.debian.net to make it clear.

## Using CI to build reverse dependencies

Salsa-CI Team is trying to provide tools for that.
ACTION: Check the current status

## Policy on multiple API versions

Q: There is currently no policy for multiple API versions to be co-installable.
A: (Tina): My answer to that has been to patch the import path so it is effectively a different package.
---
(End BoF)


Reply to: