Re: cosign update
Simon Josefsson writes: > x) github.com/sigstore/sigstore/pkg/tuf - according to upstream, TUF > support is deprecated so we dropped this part. However cosign still > uses it. There are open github issues related to TUF, but help > appreciated if anyone knows how to assist cosign upstream to drop the > github.com/sigstore/sigstore/pkg/tuf dependency, assuming that is the > right thing. I've tried to analyze the cosign relationship to TUF v0, and found this issue: https://github.com/sigstore/cosign/issues/3548 If I understand correctly, cosign v2.x will continue to depend on TUF v0 for quite some time, even when the TUF v2 support is added. This is still needed even though github.com/sigstore/sigstore-go and github.com/sigstore/sigstore are using TUF v2. Alas, maybe the transition from v0 to v2 was premature here: https://tracker.debian.org/pkg/golang-github-theupdateframework-go-tuf OTOH, we have other packages that depend on v2, such as upcoming github.com/sigstore/sigstore-go which is also a cosign dependency. So it seems there is no simple way around having BOTH v0 and v2 if we want to get current cosign into Debian. I'll experiment with creating a golang-github-theupdateframework-go-tuf-v0 source package. > x) github.com/google/go-github/v55/github - maybe just a package version > upgrade? Help appreciated. This was easy to fix: https://salsa.debian.org/go-team/packages/cosign/-/commit/dbe3954b01e5e8085e66ef45d12f1e4da10965b6 /Simon signature.asc Description: PGP signature
Admin access to my projects on go-team?
Hi! Can somebody with team-level permissions grant me project-level admin access to the projects: https://salsa.debian.org/go-team/packages/glow https://salsa.debian.org/go-team/packages/golang-github-muesli-mango-cobra https://salsa.debian.org/go-team/packages/golang-github-muesli-mango-pflag i need this to fix the default branch name in golang-github-muesli-mango-pflag to debian/latest and to play around with CI settings and protected branch settings in all of the repos. Thanks!
Bug#1088188: ITP: golang-github-notaryproject-notation-plugin-framework-go -- Contains framework or base for notation plugins
Package: wnpp Severity: wishlist Owner: Reinhard Tartler * Package name: golang-github-notaryproject-notation-plugin-framework-go Version : 1.0.0-1 Upstream Author : Notary Project * URL : https://github.com/notaryproject/notation-plugin-framework-go * License : Apache-2.0 Programming Lang: Go Description : Framework or base for notation plugins This package contains golang source-code required to create notation plugins as per Notary Project specifications (https://github.com/notaryproject/specifications).
Bug#1088197: ITP: golang-github-go-quicktest-qt -- quick helpers for testing Go applications (Go library)
Package: wnpp Severity: wishlist Owner: Simon Josefsson * Package name: golang-github-go-quicktest-qt Version : 1.101.0-1 Upstream Author : Canonical Ltd. * URL : https://github.com/go-quicktest/qt * License : Expat Programming Lang: Go Description : quick helpers for testing Go applications (Go library) qt: quicker Go tests - Package qt provides a collection of Go helpers for writing tests. It uses generics, so requires Go 1.18 at least. . For a complete API reference, see the package documentation: https://pkg.go.dev/github.com/go-quicktest/qt I hope to maintain this package as part of Debian Go Packaging Team: https://salsa.debian.org/go-team/packages/golang-github-go-quicktest-qt /Simon signature.asc Description: PGP signature
Re: Golang team Salsa CI runner and documentation
Hi all! Thanks for multiple replies on the topic after a couple weeks of silence. I am already in progress doing the things suggested here, and now with the additional feedback I think I can finalize everything today in https://salsa.debian.org/go-team/infra/pkg-go-tools/-/merge_requests/2 and start using it on my Go packages initially, and if no regressions surface perhaps proceed with the team-wide change in a couple of weeks. > 1) Patch dh-make-golang to create debian/salsa-ci.yml instead of > debian/gitlab-ci.yml, pointing to a combination of salsa CI and > test_the_world. And drop the disabling of shared runners on salsa on > create-salsa-project. Let's merge https://salsa.debian.org/go-team/infra/pkg-go-tools/-/merge_requests/2 first to update file contents, and I can follow up with file rename. > 2) On every package update, maintainers do the pipeline change > manually. > > OTOH, this costs maintainer time compared to my other plan which just > costs shared runner time. So I think this is a worse trade-off, human > time is costlier than CPU time. This is now what https://salsa.debian.org/go-team/infra/pkg-go-tools/-/merge_requests/2 does and by necessity as instance runners are not (yet) enabled in go-team. > My perception is that while definitely salsa speed could be improved, > it is not that much of a difference compared to working on gitlab.com > which I do a lot as well, and find acceptable. > > Maybe this is a question for the Salsa CI team, are they okay with > shared runner CPU time for Go packages? The Salsa CI team only maintains the CI code. We have no access or visibility into the state of Salsa itself, nor the shared runners. We for example do not know what is the capacity or utilization-% of the shared runners. We do however know that there are several hardware donors pending the Salsa Admins to accept donations (https://salsa.debian.org/salsa/support/-/issues/301) so I suspect the bottle neck here is not CPU time, but human time to maintain Salsa, and human time to maintain packages divided among doing new package versions vs fixing regressions that went into the archive. Salsa CI hopefully can save human time on the latter one, and DEP18 may help drive a culture of more team work and code reviews to improve aspects in ways that CI doesn't.
Re: Golang team Salsa CI runner and documentation
On Sun, Nov 24, 2024 at 8:56 PM Simon Josefsson wrote: > > Shengjing Zhu writes: > > > On Sun, Nov 24, 2024 at 8:31 PM Simon Josefsson wrote: > >> > >> Hi. > >> > >> I never understood what > >> the 'test_the_archive' job does or what it helps with. All failures I > >> have ever encountered are cought by the standard Salsa pipeline (and it > >> catches many other mistakes). Does 'test_the_archive' test for anything > >> that the normal Salsa pipeline would not catch? I never understood > >> that. > > > > The normal salsa CI is for QA for the package itself. > > 'test_the_archive' is something like ratt, but designed with cache and > > efficiency (well, currently broken and half implemented). But they are > > two different things. > > > > The normal salsa CI is good for "go programs", but I'm not convinced > > it's good for the large amount of "go libraries", which are just based > > on the standard template from dh-make-golang. > > Then I think both jobs are useful. The Salsa CI catches many usual > packaging mistakes for "go libraries" that "test_the_archive" doesn't > (e.g., it performs real packages builds and runs lintian). There is no > conflict with running jobs from both pipelines. There is added (of > course) CPU time to run all jobs, but presumably people donating the > shared runners believe it is worth it for better Debian package quality. > Please be aware that the large number of CI jobs not only consumes resources of gitlab runner, but also increases the load of the gitlab server. I'm already very sad with the slowness of our gitlab instance - salsa. Well you may argue that the number of go libraries is a small ratio of the whole debian packages, but I hope we can still save a little load for the salsa server. -- Shengjing Zhu
Re: Golang team Salsa CI runner and documentation
sön 2024-11-24 klockan 21:03 +0800 skrev Shengjing Zhu: > On Sun, Nov 24, 2024 at 8:56 PM Simon Josefsson > wrote: > > > > Shengjing Zhu writes: > > > > > On Sun, Nov 24, 2024 at 8:31 PM Simon Josefsson > > > wrote: > > > > > > > > Hi. > > > > > > > > I never understood what > > > > the 'test_the_archive' job does or what it helps with. All > > > > failures I > > > > have ever encountered are cought by the standard Salsa pipeline > > > > (and it > > > > catches many other mistakes). Does 'test_the_archive' test for > > > > anything > > > > that the normal Salsa pipeline would not catch? I never > > > > understood > > > > that. > > > > > > The normal salsa CI is for QA for the package itself. > > > 'test_the_archive' is something like ratt, but designed with > > > cache and > > > efficiency (well, currently broken and half implemented). But > > > they are > > > two different things. > > > > > > The normal salsa CI is good for "go programs", but I'm not > > > convinced > > > it's good for the large amount of "go libraries", which are just > > > based > > > on the standard template from dh-make-golang. > > > > Then I think both jobs are useful. The Salsa CI catches many usual > > packaging mistakes for "go libraries" that "test_the_archive" > > doesn't > > (e.g., it performs real packages builds and runs lintian). There > > is no > > conflict with running jobs from both pipelines. There is added (of > > course) CPU time to run all jobs, but presumably people donating > > the > > shared runners believe it is worth it for better Debian package > > quality. > > > > Please be aware that the large number of CI jobs not only consumes > resources of gitlab runner, but also increases the load of the gitlab > server. I'm already very sad with the slowness of our gitlab instance > - salsa. Well you may argue that the number of go libraries is a > small > ratio of the whole debian packages, but I hope we can still save a > little load for the salsa server. One compromise would be to have an opt-in transition plan: only enable Salsa shared pipeline for all packages that we upload from now going forward. Then the action plan is simpler: 1) Patch dh-make-golang to create debian/salsa-ci.yml instead of debian/gitlab-ci.yml, pointing to a combination of salsa CI and test_the_world. And drop the disabling of shared runners on salsa on create-salsa-project. 2) On every package update, maintainers do the pipeline change manually. OTOH, this costs maintainer time compared to my other plan which just costs shared runner time. So I think this is a worse trade-off, human time is costlier than CPU time. My perception is that while definitely salsa speed could be improved, it is not that much of a difference compared to working on gitlab.com which I do a lot as well, and find acceptable. Maybe this is a question for the Salsa CI team, are they okay with shared runner CPU time for Go packages? /Simon signature.asc Description: This is a digitally signed message part
Re: Golang team Salsa CI runner and documentation
Hi. I'm also +1 on including all the jobs from the standard pipeline to Go project. I create a fork for each project I work on just to be able to run the normal Salsa pipeline, for QA purposes. I never understood what the 'test_the_archive' job does or what it helps with. All failures I have ever encountered are cought by the standard Salsa pipeline (and it catches many other mistakes). Does 'test_the_archive' test for anything that the normal Salsa pipeline would not catch? I never understood that. I have a suggestion for alternative change. All Go Debian packages (to my knowledge) have a debian/gitlab-ci.yml with this content: # auto-generated, DO NOT MODIFY. # The authoritative copy of this file lives at: # https://salsa.debian.org/go-team/infra/pkg-go-tools/blob/master/config/gitlabciyml.go --- include: - https://salsa.debian.org/go-team/infra/pkg-go-tools/-/raw/master/pipeline/test-archive.yml I think we should stop this non-standard approach, to harmonize with the rest of Debian packaging. Here's my suggestion: 1) New Go projects on Salsa (dh-make-golang create-salsa-project) should set a defualt CI pipeline configuration as debian/salsa-ci.yml rather than debian/gitlab-ci.yml. 2) Change 'dh-make-golang make' to create a debian/salsa-ci.yml instead of debian/gitlab-ci.yml, and the new debian/salsa-ci.yml should look like this: # auto-generated, DO NOT MODIFY. # The authoritative copy of this file lives at: # https://salsa.debian.org/go-team/infra/pkg-go-tools/blob/master/config/gitlabciyml.go --- include: - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/recipes/debian.yml - https://salsa.debian.org/go-team/infra/pkg-go-tools/-/raw/master/pipeline/go-jobs.yml Maybe we should pick a new authorative filename since we are introducing big changes. 3) Create the 'go-jobs.yml' file to run the 'test_the_archive' job in parallel with the standard Salsa pipeline. 4) Modify https://salsa.debian.org/go-team/infra/pkg-go-tools/-/raw/master/pipeline/test-archive.yml to include the default Salsa pipeline plus run 'test_the_archive' job, maybe via go-jobs.yml or inside current test-archive.yml. The purpose is to make all existing Go packages with debian/gitlab-ci.yml begin to use the standard Salsa pipeline, without any changes to the packaging. 5) Some configuration changes are needed to enable Shared Runners on all existing Go projects. Currently 'dh-make-golang create-salsa-project' disable the shared runners. Should we do a one-pass script to enable shared runners on all Go Salsa projects? Thoughts? /Simon Nilesh Patra writes: > On 24/11/24 09:43, Otto Kekäläinen wrote: >> Hi! >> Are Go team members interested in being able to run plain Salsa CI >> on >> their packages? > > If I am not mistaken, by plain salsa CI you mean this thing > https://salsa.debian.org/salsa-ci-team/pipeline > right? > > I think so. This DC there was a discussion of getting rid of the legacy go > salsa CI since the > go world has moved from untagged repos to following good semver practices. > > Here are the notes for your ref: > https://salsa.debian.org/debconf-team/public/data/dc24/-/blob/main/etherpad/txt/152-go-team-bof.txt > > I personally use salsa CI pipeline (not the go one) for a couple of end user > apps that I maintain. > >> I have posted a Merge Request at >> https://salsa.debian.org/go-team/infra/pkg-go-tools/-/merge_requests/2 >> for discussion. >> Example of it being used: >> https://salsa.debian.org/otto/golang-github-tomasen-fcgi-client/-/pipelines/751593 >> ... On Tue, 17 Sept 2024 at 01:16, Otto Kekäläinen wrote: > > Hi! > > I noticed the Go team has docs for having your own Salsa CI runner: > https://go-team.pages.debian.net/ci.html > > There are also Ansible scripts to deploy it at > https://salsa.debian.org/go-team/infra/provisioning/-/tree/master/ci-runner, > though the runner configuration is not fully identical to the docs. > > Perhaps this practice of having team-runners would make sense for > other teams as well? > > We recently added in Salsa CI the doc > https://salsa.debian.org/salsa-ci-team/pipeline/-/blob/master/RUNNERS.md, > and I wanted to invite you to contribute to it in case you have best > practices to share or if somebody wants to refactor the Ansible script > you have and make it generic enough to be something we could recommend > for any team or DD to use across Debian, and potentially distributed > as a single file/directory from a centralized place. > > - Otto >> > signature.asc Description: PGP signature
Re: Golang team Salsa CI runner and documentation
On Sun, Nov 24, 2024 at 8:31 PM Simon Josefsson wrote: > > Hi. > > I never understood what > the 'test_the_archive' job does or what it helps with. All failures I > have ever encountered are cought by the standard Salsa pipeline (and it > catches many other mistakes). Does 'test_the_archive' test for anything > that the normal Salsa pipeline would not catch? I never understood > that. The normal salsa CI is for QA for the package itself. 'test_the_archive' is something like ratt, but designed with cache and efficiency (well, currently broken and half implemented). But they are two different things. The normal salsa CI is good for "go programs", but I'm not convinced it's good for the large amount of "go libraries", which are just based on the standard template from dh-make-golang. -- Shengjing Zhu
Re: golang-github-lestrrat-go-jwx
Progress update: I've tried to reach out to minio/pkg upstream and ask them to bump to go-jwx v2: https://github.com/minio/pkg/pull/139 Upstream lestrrat-go/jwx commented on minio/pkg here: https://github.com/lestrrat-go/jwx/issues/1239#issuecomment-2495080886 Let's wait some time and see if they address it, otherwise I think the golang-github-lestrrat-go-jwx-v2 path is unavoidable. /Simon Simon Josefsson writes: > Hi > > The golang-github-lestrrat-go-jwx package contains the v1 branch, which > upstream says is archived: > > https://github.com/lestrrat-go/jwx/tree/v1?tab=readme-ov-file#users-of-githubcomlestrratgo-jwx > > The v2 and v3 branches seems recommended. > > I'm considering packaging buildkit (an avoidable dependency of cosign) > which depends on buildkite-go-pipeline that uses the v2 branch of > lestrrat-go-jwx. > > I tried upgrading golang-github-lestrrat-go-jwx to v2 but then the > single reverse dependency golang-github-minio-pkg isn't happy: > > https://salsa.debian.org/jas/golang-github-lestrrat-go-jwx/-/jobs/6622218 > > dpkg-checkbuilddeps: error: Unmet build dependencies: > golang-github-lestrrat-go-jwx-dev (<< 2.0) > > Alas upstream seems to have disabled bug reporting: > https://github.com/minio/pkg > > Is there any way out of this except adding > golang-github-lestrrat-go-jwx-v2 that provide the v2 branch? > > Could we get minio/pkg to use the v2 branch, and update > golang-github-lestrrat-go-jwx to v2? > > I'm going down the golang-github-lestrrat-go-jwx-v2 route now, but > wanted to bring this up before filing ITP and doing the NEW upload. > > /Simon > signature.asc Description: PGP signature
Re: Golang team Salsa CI runner and documentation
On Sun, Nov 24, 2024 at 7:42 AM Shengjing Zhu wrote: > On Sun, Nov 24, 2024 at 8:31 PM Simon Josefsson > wrote: > > > > Hi. > > > > I never understood what > > the 'test_the_archive' job does or what it helps with. All failures I > > have ever encountered are cought by the standard Salsa pipeline (and it > > catches many other mistakes). Does 'test_the_archive' test for anything > > that the normal Salsa pipeline would not catch? I never understood > > that. > > The normal salsa CI is for QA for the package itself. > 'test_the_archive' is something like ratt, but designed with cache and > efficiency (well, currently broken and half implemented). But they are > two different things. > > The normal salsa CI is good for "go programs", but I'm not convinced > it's good for the large amount of "go libraries", which are just based > on the standard template from dh-make-golang. > We have a significant amount of packages that build both a library as well as a program. I think running both both provides significant value for a large number of packages! -- regards, Reinhard
Re: Golang team Salsa CI runner and documentation
Shengjing Zhu writes: > On Sun, Nov 24, 2024 at 8:31 PM Simon Josefsson wrote: >> >> Hi. >> >> I never understood what >> the 'test_the_archive' job does or what it helps with. All failures I >> have ever encountered are cought by the standard Salsa pipeline (and it >> catches many other mistakes). Does 'test_the_archive' test for anything >> that the normal Salsa pipeline would not catch? I never understood >> that. > > The normal salsa CI is for QA for the package itself. > 'test_the_archive' is something like ratt, but designed with cache and > efficiency (well, currently broken and half implemented). But they are > two different things. > > The normal salsa CI is good for "go programs", but I'm not convinced > it's good for the large amount of "go libraries", which are just based > on the standard template from dh-make-golang. Then I think both jobs are useful. The Salsa CI catches many usual packaging mistakes for "go libraries" that "test_the_archive" doesn't (e.g., it performs real packages builds and runs lintian). There is no conflict with running jobs from both pipelines. There is added (of course) CPU time to run all jobs, but presumably people donating the shared runners believe it is worth it for better Debian package quality. /Simon signature.asc Description: PGP signature
Bug#1088181: ITP: golang-github-emicklei-proto -- parser for Google ProtocolBuffers definition
Package: wnpp Severity: wishlist Owner: Simon Josefsson * Package name: golang-github-emicklei-proto Version : 1.13.2-1 Upstream Author : Ernest Micklei * URL : https://github.com/emicklei/proto * License : Expat Programming Lang: Go Description : parser for Google ProtocolBuffers definition Package in Go for parsing Google Protocol Buffers .proto files version 2 + 3 (https://developers.google.com/protocol-buffers/docs/reference/proto3- spec) I hope to maintain this package as part of Debian Go Packaging Team: https://salsa.debian.org/go-team/packages/golang-github-emicklei-proto /Simon signature.asc Description: PGP signature
Bug#1088182: ITP: golang-github-protocolbuffers-txtpbfmt -- txtpbfmt parses, edits and formats text proto files in a way that preserves comments.
Package: wnpp Severity: wishlist Owner: Simon Josefsson * Package name: golang-github-protocolbuffers-txtpbfmt Version : 0.0~git20241112.20d2c9e-1 Upstream Author : Protocol Buffers * URL : https://github.com/protocolbuffers/txtpbfmt * License : Apache-2.0 Programming Lang: Go Description : txtpbfmt parses, edits and formats text proto files in a way that preserves comments. txtpbfmt parses, edits and formats text proto files in a way that preserves comments. . * Text Format Language Specification (https://developers.google.com/protocol-buffers/docs/text-format-spec) I hope to maintain this package as part of Debian Go Packaging Team: https://salsa.debian.org/go-team/packages/golang-github-protocolbuffers-txtpbfmt /Simon signature.asc Description: PGP signature
Bug#1088184: ITP: golang-github-cue-lang-cue -- CUE language - Validate and define text-based and dynamic configuration
Package: wnpp Severity: wishlist Owner: Simon Josefsson * Package name: golang-github-cue-lang-cue Version : 0.12.0-0~dev-1 Upstream Author : The CUE Authors * URL : https://github.com/cue-lang/cue * License : Apache-2.0 Programming Lang: Go Description : CUE language - Validate and define text-based and dynamic configuration CUE - *Configure, Unify, Execute* . CUE makes it easy to validate data, write schemas, and ensure configurations align with policies. . CUE works with a wide range of tools and formats that you're already using such as Go, JSON, YAML, OpenAPI, and JSON Schema. I hope to maintain this package as part of Debian Go Packaging Team: https://salsa.debian.org/go-team/packages/golang-github-cue-lang-cue /Simon signature.asc Description: PGP signature
Bug#1088183: ITP: golang-github-cue-labs-oci -- Go modules related to OCI (Open Container Initiative) registries
Package: wnpp Severity: wishlist Owner: Simon Josefsson * Package name: golang-github-cue-labs-oci Version : 0.0~git20240906.82eb438-1 Upstream Author : The CUE Authors * URL : https://github.com/cue-labs/oci * License : Apache-2.0 Programming Lang: Go Description : Go modules related to OCI (Open Container Initiative) registries This repository holds functionality related to OCI (Open Container Initiative). Currently it holds only a single module: ociregistry. See the documentation for that package (/ociregistry) for details. I hope to maintain this package as part of Debian Go Packaging Team: https://salsa.debian.org/go-team/packages/golang-github-cue-labs-oci /Simon signature.asc Description: PGP signature
Bug#1088206: ITP: glow -- Render Markdown on the CLI
Package: wnpp Severity: wishlist Owner: Otto Kekäläinen * Package name: glow Version : 1.2.0-1 Upstream Author : Charm * URL : https://github.com/charmbracelet/glow * License : Expat Programming Lang: Go Description : Render Markdown on the CLI Glow is a terminal based Markdown reader designed from the ground up to bring out the beauty—and power—of the CLI. Use it to discover markdown files, read documentation directly on the command line. Glow will find local Markdown files in subdirectories or a local git repository. See also ITP for golang-github-muesli-mango-cobra and golang-github-muesli-mango-pflag.
Bug#1088208: ITP: golang-github-muesli-mango-pflag -- pflag adapter for mango
Package: wnpp Severity: wishlist Owner: Otto Kekäläinen * Package name: golang-github-muesli-mango-pflag Version : 0.1.0-1 Upstream Author : Christian Muehlhaeuser * URL : https://github.com/muesli/mango-pflag * License : Expat Programming Lang: Go Description : pflag adapter for mango mango-pflag is a pflag adapter for mango (https://github.com/muesli/mango) I intend to package Glow (https://github.com/charmbracelet/glow) for Debian, and this is an indirect dependency of it.
Bug#1088207: ITP: golang-github-muesli-mango-cobra -- cobra adapter for mango
Package: wnpp Severity: wishlist Owner: Otto Kekäläinen * Package name: golang-github-muesli-mango-cobra Version : 1.2.0-1 Upstream Author : Christian Muehlhaeuser * URL : https://github.com/muesli/mango-cobra * License : Expat Programming Lang: Go Description : cobra adapter for mango mango-cobra is a cobra adapter for mango (https://github.com/muesli/mango) I intend to package Glow (https://github.com/charmbracelet/glow) for Debian, and this is an indirect dependency of it.
Re: Admin access to my projects on go-team?
Hi. I tried to enable this now, does it work? /Simon signature.asc Description: PGP signature
