Debian Golang Packaging Team BOF Aug 26 (Wed): 12:00 UTC If you want to participate, ask the link to nodens on IRC! Potential Agenda: --------------------- 1. Welcome, who's there? 2. Review items from last year's agenda 1. Welcome to this BoF ------------ Please introduce yourself briefly by telling us: * What's your name & nick Clément Hermann (nodens) Luna Jernberg (bittin) (helping writing, but don't have any mic) Reinhard Tartler (siretart) Lucas Kanashiro (kanashiro) Anthony Fok (foka) Utkarsh Gupta (utkarsh2102) Michael Banck Nilesh Patra (gargantua_kerr) Pirate Praveen (j4v4m4n) - listening only Tong Sun (suntong) - listening only Wookey (etherpad+stream) Guillem Jover Shengjing (zhsj) * What do you do in Debian 2. Gomod issue (GOPATH is being deprecated) Shengjing (zhjs) did some tests https://lists.debian.org/debian-go/2020/02/msg00011.html zhjs proposes to use a completely different approach to rewrite to go.mod file instead of using a tmp directory to not have to copy the temporary directory a lot, maybe having some alternatives, do we have to do this before Bullseye 11 or can we wait another release to 12 how fast should we update the Go package to new versions? It would be nice to start the work early with experimental but we have to prioritize our work as the freeze for the next release is in 6 months Probably we have to see how many packages are affected. Still needs work on dh-golang, though. [foka] (Yes, I think adding support for it in dh-golang and dh-make-golang comes first; migration of packages come later.) https://lists.debian.org/debian-go/2020/06/msg00002.html go seems still supporting gopath for modules. 3. Migrate away Built-Using proposal: create X-Go-Built-Using. What tooling needs change? Can FTP Master check what tooling for each package that is already in Debian? - some packages still need it for legal reasons (e.g. Apache2 license), how to identify them? - The policy now prevents us from using the Built-Using field, but as all our packages are statically linked we need to know what package ???? depends on each other in the building process To check: dh-golang dh-make-golang Lintian warning/error Q: Have you considered using the information contained in the buildinfo files instead? Using a field per lang makes this a bit brittle to support in generic tooling like dpkg. -- having it in the metadata makes this information very accessible, you can just check the Sources index to learn what package was used. Perhaps the buildinfo data should become more acceassible? :) - There's also https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/commit/?h=pu/substvars-built-using&id=ac0212ab72738ff441437d107a2fb554be5f8425, which is not ready (and would need support for a newly named field for this different purpose), but that does not seem to scale to what the go team (or others using the statically linked scheme) would want. I guess this would need to be done by somehow marking the built-using packages on their source so that a generic tool could check the list of Build-Depends* and add those into the generated binary packages, or something along those lines. Q: is go ever moving away from static linking? +1 - I don't see that happening - (well, at least we are already dynamically linking with libc. ). Right. So it can do it...Why not use it more, as it solves a lot of issues? Q: Go has the ability to do dynamic link now, right? A: It exists in the Go-Tooling but no one is using that, and we are gonna have a lot of issues if we are doing that and we should not try to convience upstreams like etcd for example to use Dynamic linking instead When you have to update a Go-package you have to work a lot on Autopkgs and you have to know what packages has to be rebuilt and its a bug that the source code can not be downloaded from the main archive and merging things from the archives, might make security problems public that should not be public We need someone that can code Python to help us with looking at things(i sent an email to the Debian-Security, Debian-Go and Debian-Release Mailinglist asking for help) Security Questions is not only for the Go team, we have the same problems with Haskell and OCaml and for all static linked languages this topic needs to have a lot of people discussing/working on it (Clément send an email about this in February) - We need to translate this to a TODO List for the people/programming languages with the same problem Rust BoF follows straight after this after the break, and has the same issue with static linking. Somone may wish to attend/comment. Maybe a "statically linked languages packaging teams" ad-hoc BoF might be interesting? Yes. Debian processes were fundamentally designed around a C, dynamically-linked world. Possibly we need to change some fairly fundamental things if a large fraction of the archive is statically linked. (or decide the static people are all crazy and fix things for them). We have influenced languages in the past to be less crazy WRT the distro context :-) zhsj, good to see you join us on jitsi! debconf is usually a good way of getting people's attention. maybe don't wait for them to reply by mail, try IRC instead? Perhaps we can arrange more jitsi meeting(s) after DebConf to follow up on these issues. It would be nice to meet everyone more often throughout the year. :-) File a RM for package ????? X. Review Other Items from last year's agenda (ongoing or unresolved) -------------- Last years agenda: (report: https://lists.debian.org/debian-go/2020/01/msg00055.html ) - Go library transition and rebuild issue https://wiki.debian.org/Teams/DebianGoTeam/2020/GoEcosystemIssues still an issue, needs work on dak that no one commited to do. Mail sent to security and release team: let's move forward, please help if you can! - major upstream releases during buster freeze we need to avoid uploading new releases in unstable during freeze: use experimental Make people aware that they are doing that (as dependices is gonna be broken then)(maybe we can use salsaci things to help us with this check if there is issues or use a runner on your laptop) even minor update should be avoid, only uploading to unstable which can be migrated to testing during freeze. since other packages which b-d on it can't migrated. ratt as a service https://lists.debian.org/debian-devel/2020/03/msg00342.html - Workflow change https://go-team.pages.debian.net/workflow-changes.html We agreed on this, and it's the default for dh-make-golang. It could use more/better doc. Help, anyone ? See thread at https://lists.debian.org/msgid-search/b6f13b87-6eda-5539-b2e3-036ff8cbfa2f@debian.org - Using CI to build reverse dependencies AFAIK, no one checked on the salsa-ci team about that. salsa-ci is x86-only at the moment and doesn't use sbuild. no use for real builds (I want to fix this). - Policy on multiple API versions no policy written, but the usual workaround is to patch import-path when needed ----------------------------- Potential further topics: - container technologies (docker, podman, etc.) - protobuf v2: do we need to do something before Bullseye? https://lists.debian.org/debian-go/2020/07/msg00006.html today I find v2 has regression with gogo protobuf, which is