Bug#1060839: ITP: golang-github-adamkorcz-go-fuzz-headers-1 -- helper functions for Go fuzzing (library)
On Tue, Jan 16, 2024 at 4:28 AM Simon Josefsson wrote: > > Shengjing Zhu writes: > > > On Mon, Jan 15, 2024 at 8:51 PM Simon Josefsson wrote: > >> > >> Package: wnpp > >> Severity: wishlist > >> Owner: Simon Josefsson > >> > >> * Package name: golang-github-adamkorcz-go-fuzz-headers-1 > >> Version : 0.0~git20230919.8b5d3ce-1 > >> Upstream Author : Adam Korcz > >> * URL : https://github.com/AdamKorcz/go-fuzz-headers-1 > >> * License : Apache-2.0 > >> Programming Lang: Go > >> Description : helper functions for Go fuzzing (library) > >> > >> Various helper functions for go fuzzing. It is mostly used in combination > >> with go-fuzz (https://github.com/dvyukov/go-fuzz), but compatibility with > >> fuzzing in the standard library will also be supported. Any coverage > >> guided > >> fuzzing engine that provides an array or slice of bytes can be used with > >> go-fuzz-headers. > >> . > >> go-fuzz-headers' approach to fuzzing structs is strongly inspired by > >> gofuzz (https://github.com/google/gofuzz). > >> > >> I hope to maintain this package as part of Debian Go Packaging Team: > >> > >> https://salsa.debian.org/go-team/packages/golang-github-adamkorcz-go-fuzz-headers-1/ > >> > > > > Usually we don't run fuzz test when building packages, because it > > would waste a lot of buildd resource. > > > > In theory we don't need any fuzz related libraries. But upstream may > > mix their unit tests and fuzz tests in one source file, which makes it > > difficult to strip such tests and their libraries. > > The Go compiler by default wouldn't run fuzz tests. > > > > For packaging rekor, I think all these fuzz tests can be stripped by > > file names. It seems upstream just puts all fuzz tests in > > "fuzz_test.go". > > What is the best method to modify rekor to not need this dependency? > > If rekor can work without this package, I'm happy to avoid packaging it, > although it is already in NEW. > > Looking at code, it seems to be used here: > > go.sum:github.com/AdamKorcz/go-fuzz-headers-1 > v0.0.0-20230618160516-e936619f9f18 > h1:rd389Q26LMy03gG4anandGFC2LW/xvjga5GezeeaxQk= > go.sum:github.com/AdamKorcz/go-fuzz-headers-1 > v0.0.0-20230618160516-e936619f9f18/go.mod > h1:fgJuSBrJP5qZtKqaMJE0hmhS2tmRH+44IkfZvjtaf1M= > hack/tools/go.sum:github.com/AdamKorcz/go-fuzz-headers-1 > v0.0.0-2023032938-12e09aba5ebd > h1:1tbEqR4NyQLgiod7vLXSswHteGetAVZrMGCqrJxLKRs= > hack/tools/go.sum:github.com/AdamKorcz/go-fuzz-headers-1 > v0.0.0-2023032938-12e09aba5ebd/go.mod > h1:0vOOKsOMKPThRu9lQMAxcQ8D60f8U+wHXl07SyUw0+U= > hack/tools/tools.go:_ "github.com/AdamKorcz/go-fuzz-headers-1" > hack/tools/go.mod: github.com/AdamKorcz/go-fuzz-headers-1 > v0.0.0-2023032938-12e09aba5ebd > pkg/types/hashedrekord/v0.0.1/fuzz_test.go: fuzz > "github.com/AdamKorcz/go-fuzz-headers-1" > pkg/types/rpm/v0.0.1/fuzz_test.go: fuzz > "github.com/AdamKorcz/go-fuzz-headers-1" > pkg/types/alpine/v0.0.1/fuzz_test.go: fuzz > "github.com/AdamKorcz/go-fuzz-headers-1" > pkg/types/alpine/fuzz_test.go: fuzz "github.com/AdamKorcz/go-fuzz-headers-1" > pkg/types/cose/v0.0.1/fuzz_test.go: fuzz > "github.com/AdamKorcz/go-fuzz-headers-1" > pkg/types/jar/v0.0.1/fuzz_test.go: fuzz > "github.com/AdamKorcz/go-fuzz-headers-1" > pkg/types/rekord/v0.0.1/fuzz_test.go: fuzz > "github.com/AdamKorcz/go-fuzz-headers-1" > pkg/types/intoto/v0.0.1/fuzz_test.go: fuzz > "github.com/AdamKorcz/go-fuzz-headers-1" > pkg/types/intoto/v0.0.2/fuzz_test.go: fuzz > "github.com/AdamKorcz/go-fuzz-headers-1" > pkg/types/tuf/v0.0.1/fuzz_test.go: fuzz > "github.com/AdamKorcz/go-fuzz-headers-1" > pkg/types/helm/v0.0.1/fuzz_test.go: fuzz > "github.com/AdamKorcz/go-fuzz-headers-1" > pkg/types/dsse/v0.0.1/fuzz_test.go: fuzz > "github.com/AdamKorcz/go-fuzz-headers-1" > pkg/types/rfc3161/v0.0.1/fuzz_test.go: fuzz > "github.com/AdamKorcz/go-fuzz-headers-1" > pkg/fuzz/alpine_utils.go: fuzz "github.com/AdamKorcz/go-fuzz-headers-1" > pkg/fuzz/fuzz_utils.go: fuzz "github.com/AdamKorcz/go-fuzz-headers-1" > pkg/fuzz/jar_utils.go: fuzz "github.com/AdamKorcz/go-fuzz-headers-1" > go.mod: github.com/AdamKorcz/go-fuzz-headers-1 > v0.0.0-20230618160516-e936619f9f18 > > Would we have to patch all of these files? Or disable building them > somehow? > Just remove these files, either via Files-Excluded in debian/copyright, or rm in builddir in debian/rules. > Let's see if we can develop a workaround before ftp-master approves the > packages... otherwise maybe it doesn't hurt to use it anyway, and may > save us time maintaining patches. > > /Simon -- Shengjing Zhu
Bug#1060891: O: pacparser -- library to parse proxy auto-config files (development files)
Package: wnpp Severity: normal X-Debbugs-Cc: pacpar...@packages.debian.org Control: affects -1 + src:pacparser pacparser is orphaned https://github.com/manugarg/pacparser/issues/185
Processed: O: pacparser -- library to parse proxy auto-config files (development files)
Processing control commands: > affects -1 + src:pacparser Bug #1060891 [wnpp] O: pacparser -- library to parse proxy auto-config files (development files) Added indication that 1060891 affects src:pacparser -- 1060891: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060891 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1060888: RFP: typst -- A new markup-based typesetting system that is powerful and easy to learn.
Package: wnpp Severity: wishlist * Package name : typst Version : 0.10.0 Upstream Contact: Martin Haug * URL : https://github.com/typst/typst * License : Apache 2.0 Programming Lang: Rust Description : A new markup-based typesetting system that is powerful and easy to learn. Typst is a new typesetting system based on Rust, designed as a modern alternative to LaTeX. It's relatively new, only released last year, but growing in popularity (almost 25k stars on Github), and it's usable enough that myself and others have adopted it for writing academic papers. Typst can be used via a web app, but this submission is for the command line interface: typst-cli. I am neither a Typst developer nor an existing Debian maintainer, but I am submitting this for consideration by the Debian Rust packaging team.
Processed: ITP watchfiles
Processing commands for cont...@bugs.debian.org: > owner 1028916 po...@debian.org Bug #1028916 [wnpp] RFP: watchfiles -- Simple, modern and fast file watching and code reload in python. Owner recorded as po...@debian.org. > retitle 1028916 ITP: watchfiles -- Simple, modern and fast file watching and > code reload in python. Bug #1028916 [wnpp] RFP: watchfiles -- Simple, modern and fast file watching and code reload in python. Changed Bug title to 'ITP: watchfiles -- Simple, modern and fast file watching and code reload in python.' from 'RFP: watchfiles -- Simple, modern and fast file watching and code reload in python.'. > thanks Stopping processing here. Please contact me if you need assistance. -- 1028916: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028916 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1060880: ITP: altdns -- Subdomain discovery through alterations and permutations
Package: wnpp Severity: wishlist Owner: Josenilson Ferreira da Silva X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com * Package name: altdns Version : 1.0.2 Upstream Contact: Shubham Shah * URL : https://github.com/infosec-au/altdns * License : GPL-2.0 Programming Lang: Python Description : Subdomain discovery through alterations and permutations This package contains a DNS recon tool that allows for the discovery of subdomains that conform to patterns. Altdns takes in words that could be present in subdomains under a domain (such as test, dev, staging) as well as takes in a list of subdomains that you know of. . From these two lists that are provided as input to altdns, the tool then generates a massive output of "altered" or "mutated" potential subdomains that could be present. It saves this output so that it can then be used by your favourite DNS bruteforcing tool.
Bug#1060839: ITP: golang-github-adamkorcz-go-fuzz-headers-1 -- helper functions for Go fuzzing (library)
Shengjing Zhu writes: > On Mon, Jan 15, 2024 at 8:51 PM Simon Josefsson wrote: >> >> Package: wnpp >> Severity: wishlist >> Owner: Simon Josefsson >> >> * Package name: golang-github-adamkorcz-go-fuzz-headers-1 >> Version : 0.0~git20230919.8b5d3ce-1 >> Upstream Author : Adam Korcz >> * URL : https://github.com/AdamKorcz/go-fuzz-headers-1 >> * License : Apache-2.0 >> Programming Lang: Go >> Description : helper functions for Go fuzzing (library) >> >> Various helper functions for go fuzzing. It is mostly used in combination >> with go-fuzz (https://github.com/dvyukov/go-fuzz), but compatibility with >> fuzzing in the standard library will also be supported. Any coverage guided >> fuzzing engine that provides an array or slice of bytes can be used with >> go-fuzz-headers. >> . >> go-fuzz-headers' approach to fuzzing structs is strongly inspired by >> gofuzz (https://github.com/google/gofuzz). >> >> I hope to maintain this package as part of Debian Go Packaging Team: >> >> https://salsa.debian.org/go-team/packages/golang-github-adamkorcz-go-fuzz-headers-1/ >> > > Usually we don't run fuzz test when building packages, because it > would waste a lot of buildd resource. > > In theory we don't need any fuzz related libraries. But upstream may > mix their unit tests and fuzz tests in one source file, which makes it > difficult to strip such tests and their libraries. > The Go compiler by default wouldn't run fuzz tests. > > For packaging rekor, I think all these fuzz tests can be stripped by > file names. It seems upstream just puts all fuzz tests in > "fuzz_test.go". What is the best method to modify rekor to not need this dependency? If rekor can work without this package, I'm happy to avoid packaging it, although it is already in NEW. Looking at code, it seems to be used here: go.sum:github.com/AdamKorcz/go-fuzz-headers-1 v0.0.0-20230618160516-e936619f9f18 h1:rd389Q26LMy03gG4anandGFC2LW/xvjga5GezeeaxQk= go.sum:github.com/AdamKorcz/go-fuzz-headers-1 v0.0.0-20230618160516-e936619f9f18/go.mod h1:fgJuSBrJP5qZtKqaMJE0hmhS2tmRH+44IkfZvjtaf1M= hack/tools/go.sum:github.com/AdamKorcz/go-fuzz-headers-1 v0.0.0-2023032938-12e09aba5ebd h1:1tbEqR4NyQLgiod7vLXSswHteGetAVZrMGCqrJxLKRs= hack/tools/go.sum:github.com/AdamKorcz/go-fuzz-headers-1 v0.0.0-2023032938-12e09aba5ebd/go.mod h1:0vOOKsOMKPThRu9lQMAxcQ8D60f8U+wHXl07SyUw0+U= hack/tools/tools.go:_ "github.com/AdamKorcz/go-fuzz-headers-1" hack/tools/go.mod: github.com/AdamKorcz/go-fuzz-headers-1 v0.0.0-2023032938-12e09aba5ebd pkg/types/hashedrekord/v0.0.1/fuzz_test.go: fuzz "github.com/AdamKorcz/go-fuzz-headers-1" pkg/types/rpm/v0.0.1/fuzz_test.go: fuzz "github.com/AdamKorcz/go-fuzz-headers-1" pkg/types/alpine/v0.0.1/fuzz_test.go: fuzz "github.com/AdamKorcz/go-fuzz-headers-1" pkg/types/alpine/fuzz_test.go: fuzz "github.com/AdamKorcz/go-fuzz-headers-1" pkg/types/cose/v0.0.1/fuzz_test.go: fuzz "github.com/AdamKorcz/go-fuzz-headers-1" pkg/types/jar/v0.0.1/fuzz_test.go: fuzz "github.com/AdamKorcz/go-fuzz-headers-1" pkg/types/rekord/v0.0.1/fuzz_test.go: fuzz "github.com/AdamKorcz/go-fuzz-headers-1" pkg/types/intoto/v0.0.1/fuzz_test.go: fuzz "github.com/AdamKorcz/go-fuzz-headers-1" pkg/types/intoto/v0.0.2/fuzz_test.go: fuzz "github.com/AdamKorcz/go-fuzz-headers-1" pkg/types/tuf/v0.0.1/fuzz_test.go: fuzz "github.com/AdamKorcz/go-fuzz-headers-1" pkg/types/helm/v0.0.1/fuzz_test.go: fuzz "github.com/AdamKorcz/go-fuzz-headers-1" pkg/types/dsse/v0.0.1/fuzz_test.go: fuzz "github.com/AdamKorcz/go-fuzz-headers-1" pkg/types/rfc3161/v0.0.1/fuzz_test.go: fuzz "github.com/AdamKorcz/go-fuzz-headers-1" pkg/fuzz/alpine_utils.go: fuzz "github.com/AdamKorcz/go-fuzz-headers-1" pkg/fuzz/fuzz_utils.go: fuzz "github.com/AdamKorcz/go-fuzz-headers-1" pkg/fuzz/jar_utils.go: fuzz "github.com/AdamKorcz/go-fuzz-headers-1" go.mod: github.com/AdamKorcz/go-fuzz-headers-1 v0.0.0-20230618160516-e936619f9f18 Would we have to patch all of these files? Or disable building them somehow? Let's see if we can develop a workaround before ftp-master approves the packages... otherwise maybe it doesn't hurt to use it anyway, and may save us time maintaining patches. /Simon signature.asc Description: PGP signature
Bug#1060840: ITP: golang-k8s-sigs-release-utils -- utilities for kubernetes Go release engineering (library)
Shengjing Zhu writes: >> https://salsa.debian.org/jas/golang-github-sigstore-rekor/-/jobs/5160982 >> >> src/github.com/sigstore/rekor/cmd/backfill-redis/main.go:44:2: >> cannot find package "sigs.k8s.io/release-utils/version" in any of: >> /usr/lib/go-1.21/src/sigs.k8s.io/release-utils/version (from $GOROOT) >> >> /builds/jas/golang-github-sigstore-rekor/debian/output/source_dir/_build/src/sigs.k8s.io/release-utils/version >> (from $GOPATH) >> >> Use is here: >> >> https://github.com/sigstore/rekor/blob/main/cmd/backfill-redis/main.go#L44 > > Hmm, then this library is needed. > > However I just checked the code in sigs.k8s.io/release-utils/version, > I'm afraid it's not compatible with how we build Go binaries in > Debian. > We don't have any VCS info when building the binaries. And we use > GOPATH mde as well. So the Go compiler can't inject any version info > in the binaries. > This code > https://github.com/sigstore/rekor/blob/main/cmd/backfill-redis/main.go#L103 > would probably just print "unknown, unknown"... Can we patch rekor to not use sigs.k8s.io? Deciding matters like that is a bit beyond my focus right now, but very happy to discuss and take advice (or patches) here. That sigs.k8s.io/release-utils package needs the following dependencies that we wouldn't have to package if we can someohow get rid of it as a depedency for rekor. https://salsa.debian.org/jas/golang-k8s-sigs-release-utils/-/jobs/5161034 src/sigs.k8s.io/release-utils/mage/cosign.go:24:2: cannot find package "github.com/uwu-tools/magex/pkg" in any of: src/sigs.k8s.io/release-utils/version/version.go:30:2: cannot find package "github.com/common-nighthawk/go-figure" in any of: /Simon signature.asc Description: PGP signature
[bts-link] source package wnpp
# # bts-link upstream status pull for source package wnpp # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # https://bts-link-team.pages.debian.net/bts-link/ # user debian-bts-l...@lists.debian.org # remote status report for #923303 (http://bugs.debian.org/923303) # Bug title: RFP: mlv-app -- Magic Lantern Video processing # * https://github.com/ilia3101/MLV-App/issues/278 # * remote status changed: (?) -> open usertags 923303 + status-open # remote status report for #1036754 (http://bugs.debian.org/1036754) # Bug title: ITP: spack -- flexible package manager for supercomputer # * https://github.com/spack/spack/issues/14130 # * remote status changed: (?) -> closed # * closed upstream tags 1036754 + fixed-upstream usertags 1036754 + status-closed thanks
Processed: [bts-link] source package wnpp
Processing commands for cont...@bugs.debian.org: > # > # bts-link upstream status pull for source package wnpp > # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html > # https://bts-link-team.pages.debian.net/bts-link/ > # > user debian-bts-l...@lists.debian.org Setting user to debian-bts-l...@lists.debian.org (was debian-bts-l...@lists.debian.org). > # remote status report for #923303 (http://bugs.debian.org/923303) > # Bug title: RFP: mlv-app -- Magic Lantern Video processing > # * https://github.com/ilia3101/MLV-App/issues/278 > # * remote status changed: (?) -> open > usertags 923303 + status-open There were no usertags set. Usertags are now: status-open. > # remote status report for #1036754 (http://bugs.debian.org/1036754) > # Bug title: ITP: spack -- flexible package manager for supercomputer > # * https://github.com/spack/spack/issues/14130 > # * remote status changed: (?) -> closed > # * closed upstream > tags 1036754 + fixed-upstream Bug #1036754 [wnpp] ITP: spack -- flexible package manager for supercomputer Added tag(s) fixed-upstream. > usertags 1036754 + status-closed There were no usertags set. Usertags are now: status-closed. > thanks Stopping processing here. Please contact me if you need assistance. -- 1036754: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036754 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1060853: ITP: golang-github-sigstore-protobuf-specs -- Sigstore Protocol Buffer code (library)
Package: wnpp Severity: wishlist Owner: Simon Josefsson * Package name: golang-github-sigstore-protobuf-specs Version : 0.2.1-1 Upstream Author : sigstore * URL : https://github.com/sigstore/protobuf-specs * License : Apache-2.0 Programming Lang: Go Description : Sigstore Protocol Buffer code (library) This repository holds protobuf specifications for Sigstore messages. I hope to maintain this package as part of Debian Go Packaging Team: https://salsa.debian.org/go-team/packages/golang-github-sigstore-protobuf-specs /Simon signature.asc Description: PGP signature
Bug#1060852: ITP: golang-bitbucket-creachadair-shell -- implements basic shell command-line splitting for Go (library)
Package: wnpp Severity: wishlist Owner: Simon Josefsson * Package name: golang-bitbucket-creachadair-shell Version : 0.0.8-1 Upstream Author : Michael J. Fromberger * URL : https://bitbucket.org/creachadair/shell/ * License : BSD-3-Clause Programming Lang: Go Description : implements basic shell command-line splitting for Go (library) Provides supports for splitting and joining of shell command strings. . The Split function divides a string into whitespace-separated fields, respecting single and double quotation marks as defined by the Shell Command Language section of IEEE Std 1003.1 2013. The Quote function quotes characters that would otherwise be subject to shell evaluation, and the Join function concatenates quoted strings with spaces between them. I hope to maintain this package as part of Debian Go Packaging Team: https://salsa.debian.org/go-team/packages/golang-bitbucket-creachadair-shell/ /Simon signature.asc Description: PGP signature
Bug#1060839: ITP: golang-github-adamkorcz-go-fuzz-headers-1 -- helper functions for Go fuzzing (library)
On Mon, Jan 15, 2024 at 8:51 PM Simon Josefsson wrote: > > Package: wnpp > Severity: wishlist > Owner: Simon Josefsson > > * Package name: golang-github-adamkorcz-go-fuzz-headers-1 > Version : 0.0~git20230919.8b5d3ce-1 > Upstream Author : Adam Korcz > * URL : https://github.com/AdamKorcz/go-fuzz-headers-1 > * License : Apache-2.0 > Programming Lang: Go > Description : helper functions for Go fuzzing (library) > > Various helper functions for go fuzzing. It is mostly used in combination > with go-fuzz (https://github.com/dvyukov/go-fuzz), but compatibility with > fuzzing in the standard library will also be supported. Any coverage guided > fuzzing engine that provides an array or slice of bytes can be used with > go-fuzz-headers. > . > go-fuzz-headers' approach to fuzzing structs is strongly inspired by > gofuzz (https://github.com/google/gofuzz). > > I hope to maintain this package as part of Debian Go Packaging Team: > > https://salsa.debian.org/go-team/packages/golang-github-adamkorcz-go-fuzz-headers-1/ > Usually we don't run fuzz test when building packages, because it would waste a lot of buildd resource. In theory we don't need any fuzz related libraries. But upstream may mix their unit tests and fuzz tests in one source file, which makes it difficult to strip such tests and their libraries. The Go compiler by default wouldn't run fuzz tests. For packaging rekor, I think all these fuzz tests can be stripped by file names. It seems upstream just puts all fuzz tests in "fuzz_test.go". -- Shengjing Zhu
Bug#1060840: ITP: golang-k8s-sigs-release-utils -- utilities for kubernetes Go release engineering (library)
On Mon, Jan 15, 2024 at 10:25 PM Simon Josefsson wrote: > > Shengjing Zhu writes: > > > On Mon, Jan 15, 2024 at 9:27 PM Simon Josefsson wrote: > >> > >> Package: wnpp > >> Severity: wishlist > >> Owner: Simon Josefsson > >> > >> * Package name: golang-k8s-sigs-release-utils > >> Version : 0.7.7-1 > >> Upstream Author : Kubernetes SIGs > >> * URL : https://github.com/kubernetes-sigs/release-utils > >> * License : Apache-2.0 > >> Programming Lang: Go > >> Description : utilities for kubernetes Go release engineering > >> (library) > >> > >> Tiny utilities for use by the Release Engineering subproject and > >> kubernetes/release (https://github.com/kubernetes/release/). > >> > > > > Which package will need this library? It looks strange by the name and > > description. We certainly don't do the release stuff for kubernetes. > > Sigstore's rekor complained: > > https://salsa.debian.org/jas/golang-github-sigstore-rekor/-/jobs/5160982 > > src/github.com/sigstore/rekor/cmd/backfill-redis/main.go:44:2: cannot find > package "sigs.k8s.io/release-utils/version" in any of: > /usr/lib/go-1.21/src/sigs.k8s.io/release-utils/version (from $GOROOT) > > /builds/jas/golang-github-sigstore-rekor/debian/output/source_dir/_build/src/sigs.k8s.io/release-utils/version > (from $GOPATH) > > Use is here: > > https://github.com/sigstore/rekor/blob/main/cmd/backfill-redis/main.go#L44 > Hmm, then this library is needed. However I just checked the code in sigs.k8s.io/release-utils/version, I'm afraid it's not compatible with how we build Go binaries in Debian. We don't have any VCS info when building the binaries. And we use GOPATH mde as well. So the Go compiler can't inject any version info in the binaries. This code https://github.com/sigstore/rekor/blob/main/cmd/backfill-redis/main.go#L103 would probably just print "unknown, unknown"... > Can you think of some other solution than packaging > golang-k8s-sigs-release-utils? I would be happy to learn about > alternative approaches to reduce golang dependencies. > > /Simon -- Shengjing Zhu
Bug#1060840: ITP: golang-k8s-sigs-release-utils -- utilities for kubernetes Go release engineering (library)
Shengjing Zhu writes: > On Mon, Jan 15, 2024 at 9:27 PM Simon Josefsson wrote: >> >> Package: wnpp >> Severity: wishlist >> Owner: Simon Josefsson >> >> * Package name: golang-k8s-sigs-release-utils >> Version : 0.7.7-1 >> Upstream Author : Kubernetes SIGs >> * URL : https://github.com/kubernetes-sigs/release-utils >> * License : Apache-2.0 >> Programming Lang: Go >> Description : utilities for kubernetes Go release engineering (library) >> >> Tiny utilities for use by the Release Engineering subproject and >> kubernetes/release (https://github.com/kubernetes/release/). >> > > Which package will need this library? It looks strange by the name and > description. We certainly don't do the release stuff for kubernetes. Sigstore's rekor complained: https://salsa.debian.org/jas/golang-github-sigstore-rekor/-/jobs/5160982 src/github.com/sigstore/rekor/cmd/backfill-redis/main.go:44:2: cannot find package "sigs.k8s.io/release-utils/version" in any of: /usr/lib/go-1.21/src/sigs.k8s.io/release-utils/version (from $GOROOT) /builds/jas/golang-github-sigstore-rekor/debian/output/source_dir/_build/src/sigs.k8s.io/release-utils/version (from $GOPATH) Use is here: https://github.com/sigstore/rekor/blob/main/cmd/backfill-redis/main.go#L44 Can you think of some other solution than packaging golang-k8s-sigs-release-utils? I would be happy to learn about alternative approaches to reduce golang dependencies. /Simon signature.asc Description: PGP signature
Bug#1060840: ITP: golang-k8s-sigs-release-utils -- utilities for kubernetes Go release engineering (library)
On Mon, Jan 15, 2024 at 9:27 PM Simon Josefsson wrote: > > Package: wnpp > Severity: wishlist > Owner: Simon Josefsson > > * Package name: golang-k8s-sigs-release-utils > Version : 0.7.7-1 > Upstream Author : Kubernetes SIGs > * URL : https://github.com/kubernetes-sigs/release-utils > * License : Apache-2.0 > Programming Lang: Go > Description : utilities for kubernetes Go release engineering (library) > > Tiny utilities for use by the Release Engineering subproject and > kubernetes/release (https://github.com/kubernetes/release/). > Which package will need this library? It looks strange by the name and description. We certainly don't do the release stuff for kubernetes. -- Shengjing Zhu
Bug#1060842: ITP: trillian -- A transparent, highly scalable and cryptographically verifiable data store
Alexandre Detiste writes: > People using the non-free trillian.deb (the chat client) > will have a nasty surprise > > https://forums.debian.net/viewtopic.php?t=146679 Ouch, good catch, this needs some planning. However it is not packaged in Debian nor are there any signs of it inside the official Debian as far as I can tell. My primary use-case is the trillian golang libraries, for sigstore's rekor. I'll see about starting with them only. The 'trillian' binary package can be added later, under that name or another. /Simon > Le lun. 15 janv. 2024 à 15:03, Simon Josefsson a écrit : >> >> Package: wnpp >> Severity: wishlist >> Owner: Simon Josefsson >> >> * Package name: trillian signature.asc Description: PGP signature
Bug#1060842: ITP: trillian -- A transparent, highly scalable and cryptographically verifiable data store
People using the non-free trillian.deb (the chat client) will have a nasty surprise https://forums.debian.net/viewtopic.php?t=146679 Le lun. 15 janv. 2024 à 15:03, Simon Josefsson a écrit : > > Package: wnpp > Severity: wishlist > Owner: Simon Josefsson > > * Package name: trillian
Bug#1060842: ITP: trillian -- A transparent, highly scalable and cryptographically verifiable data store
Package: wnpp Severity: wishlist Owner: Simon Josefsson * Package name: trillian Version : 1.6.0-1 Upstream Author : Google * URL : https://github.com/google/trillian * License : Apache-2.0 Programming Lang: Go Description : A transparent, highly scalable and cryptographically verifiable data store Trillian is an implementation of the concepts described in the Verifiable Data Structures (/docs/papers/VerifiableDataStructures.pdf) white paper, which in turn is an extension and generalisation of the ideas which underpin Certificate Transparency (https://certificate- transparency.org). . Trillian implements a Merkle tree (https://en.wikipedia.org/wiki/Merkle_tree) whose contents are served from a data storage layer, to allow scalability to extremely large trees. On top of this Merkle tree, Trillian provides the following: . * An append-only **Log** mode, analogous to the original Certificate Transparency (https://certificate-transparency.org) logs. In this mode, the Merkle tree is effectively filled up from the left, giving a *dense* Merkle tree. . Certificate Transparency (CT) (https://tools.ietf.org/html/rfc6962) is the most well-known and widely deployed transparency application, and an implementation of CT as a Trillian personality is available in the certificate-transparency-go repo (https://github.com/google/certificate- transparency-go/blob/master/trillian). I hope to maintain this package as part of Debian Go Packaging Team: https://salsa.debian.org/go-team/packages/trillian /Simon signature.asc Description: PGP signature
Bug#1060841: ITP: golang-github-transparency-dev-merkle -- create and manipulate Merkle trees in Go (library)
Package: wnpp Severity: wishlist Owner: Simon Josefsson * Package name: golang-github-transparency-dev-merkle Version : 0.0.2-1 Upstream Author : Pavel Kalinnikov, Al Cutter, Martin Hutchinson, M Hickford, et al * URL : https://github.com/transparency-dev/merkle * License : Apache-2.0 Programming Lang: Go Description : create and manipulate Merkle trees in Go (library) Provides Go code to help create and manipulate Merkle trees, as well as constructing and verifying various types of proof. . This is the data structure which is used by projects such as Trillian (https://github.com/google/trillian) to provide verifiable logs (https://transparency.dev/verifiable-data-structures/#verifiable-log). I hope to maintain this package as part of Debian Go Packaging Team: https://salsa.debian.org/go-team/packages/golang-github-transparency-dev-merkle /Simon signature.asc Description: PGP signature
Bug#1060840: ITP: golang-k8s-sigs-release-utils -- utilities for kubernetes Go release engineering (library)
Package: wnpp Severity: wishlist Owner: Simon Josefsson * Package name: golang-k8s-sigs-release-utils Version : 0.7.7-1 Upstream Author : Kubernetes SIGs * URL : https://github.com/kubernetes-sigs/release-utils * License : Apache-2.0 Programming Lang: Go Description : utilities for kubernetes Go release engineering (library) Tiny utilities for use by the Release Engineering subproject and kubernetes/release (https://github.com/kubernetes/release/). I hope to maintain this package as part of Debian Go Packaging Team: https://salsa.debian.org/go-team/packages/golang-k8s-sigs-release-utils /Simon signature.asc Description: PGP signature
Bug#1060839: ITP: golang-github-adamkorcz-go-fuzz-headers-1 -- helper functions for Go fuzzing (library)
Package: wnpp Severity: wishlist Owner: Simon Josefsson * Package name: golang-github-adamkorcz-go-fuzz-headers-1 Version : 0.0~git20230919.8b5d3ce-1 Upstream Author : Adam Korcz * URL : https://github.com/AdamKorcz/go-fuzz-headers-1 * License : Apache-2.0 Programming Lang: Go Description : helper functions for Go fuzzing (library) Various helper functions for go fuzzing. It is mostly used in combination with go-fuzz (https://github.com/dvyukov/go-fuzz), but compatibility with fuzzing in the standard library will also be supported. Any coverage guided fuzzing engine that provides an array or slice of bytes can be used with go-fuzz-headers. . go-fuzz-headers' approach to fuzzing structs is strongly inspired by gofuzz (https://github.com/google/gofuzz). I hope to maintain this package as part of Debian Go Packaging Team: https://salsa.debian.org/go-team/packages/golang-github-adamkorcz-go-fuzz-headers-1/ /Simon signature.asc Description: PGP signature
Bug#842420: Status of packaging Electron?
On 15/01/24 12:08 pm, Otto Kekäläinen wrote: Hi! I am a big fan of Pulsar[1] so I filed the ITP[2] for it which led me to dive into the status of Electron[3] and NodeJS and JavaScript in Debian in general. Electron seems already to be shipped[4] among others in FreeBSD ports, Arch, Manjaro, Nix and OpenSUSE, but not in Fedora or Debian. The approach in Debian seems to be that each npm module is converted into a deb package, and thus the JS team has 1700+ packages to maintain[5]. Electron packaging has been pending for the past 7 years due to this packaging dependency requirement I assume. This requirement is relaxed these days, see https://salsa.debian.org/js-team/node-yarnpkg/-/blob/master/debian/watch?ref_type=heads for example. Some of the modules that are only useful to electron/pulsar could be included directly in that source package. You can also try to create a package in contrib first which will install dependencies via npm in postinst and gradually package the modules and later move to main. See https://salsa.debian.org/ruby-team/gitlab/-/blob/master/debian/rake-tasks.sh?ref_type=heads#L48 We also have yarn-plugin-apt which can take the apt installed modules when available and only remaining needs to be installed from npmjs.com So I guess the logical next step is just to map out all dependencies of Electron (and Pulsar) and then simply get each npm module they depend on packaged one-by-one? Can somebody who has a working setup of js_task_edit.py[6] update the Electron wiki page and also create a new one for Pulsar? And once we have the list we can start using npm2deb[7] and following the NodeJS packaging guide[8] we just package the modules and see how far we get with reasonable effort? - Otto [1] https://optimizedbyotto.com/post/pulsar-best-text-file-and-code-editor/ [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060778 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842420 [4] https://repology.org/project/electron/versions [5] https://qa.debian.org/developer.php?login=pkg-javascript-de...@lists.alioth.debian.org [6] https://wiki.debian.org/Javascript/Nodejs/Tasks [7] https://wiki.debian.org/Javascript/Nodejs/Npm2Deb [8] https://wiki.debian.org/Javascript/Nodejs/Manual OpenPGP_0x8F53E0193B294B75.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1060836: ITP: golang-github-cavaliergopher-rpm -- A Go implementation of the RPM file format
Package: wnpp Severity: wishlist Owner: Simon Josefsson * Package name: golang-github-cavaliergopher-rpm Version : 1.2.0-1 Upstream Author : Ryan Armstrong, et al * URL : https://github.com/cavaliergopher/rpm * License : BSD-3-clause Programming Lang: Go Description : Go implementation of the RPM file format (library) This implements the rpm package file format as a Go library . See the package documentation (https://pkg.go.dev/github.com/cavaliergopher/rpm) to get started. I hope to maintain this package as part of Debian Go Packaging Team: https://salsa.debian.org/go-team/packages/golang-github-cavaliergopher-rpm /Simon signature.asc Description: PGP signature
Bug#1060834: ITP: golang-github-veraison-go-cose -- go library for CBOR Object Signing and Encryption (COSE)
Package: wnpp Severity: wishlist Owner: Simon Josefsson * Package name: golang-github-veraison-go-cose Version : 1.2.1-1 Upstream Author : Veraison * URL : https://github.com/veraison/go-cose * License : MPL-2.0 Programming Lang: Go Description : go library for CBOR Object Signing and Encryption (COSE) A golang library for the COSE specification (https://datatracker.ietf.org/doc/rfc9052/) I hope to maintain this package as part of Debian Go Packaging Team: https://salsa.debian.org/go-team/packages/golang-github-veraison-go-cose /Simon signature.asc Description: PGP signature
Bug#1060820: ITP: golang-github-cyberphone-json-canonicalization -- JSON Canonicalization Scheme (JCS) (Go library)
Reinhard Tartler writes: > On Sun, Jan 14, 2024 at 8:36 PM Simon Josefsson wrote: > >> Package: wnpp >> Severity: wishlist >> Owner: Simon Josefsson >> >> * Package name: golang-github-cyberphone-json-canonicalization >> Version : 0.0~git20220623.57a0ce2-1 >> Upstream Author : Anders Rundgren >> * URL : https://github.com/cyberphone/json-canonicalization >> * License : Apache-2.0 >> Programming Lang: Go >> Description : JSON Canonicalization Scheme (JCS) (Go library) >> >> > I contemplated packaging this library in the past, but found it actually > contains > a lot of other stuff I didn't nede. In the end, I ended up packaging > https://salsa.debian.org/debian/golang-webpki-org-jsoncanonicalizer > which seems to be what the proposed package is "repackaing". > > In a way, I went straight for the source, I guess. Thanks -- I missed your package! No ITP bug? Your package looks cleaner, and I haven't yet figured out how to repack the golang-github-cyberphone-json-canonicalization tarball to only contain the Go code, much in the same way you did but instead extracted only the source code. I am considering to use your package instead, and haven't made the ftp-master NEW upload yet for 1060820. I wasn't able to build your package, did you forgot to push upstream branch and tags? Rekor has github.com/cyberphone/json-canonicalization in go.mod and is using that namespace: jas@kaka:~/dpkg/golang-github-sigstore-rekor$ rgrep jsoncanonicalizer . ./tests/e2e_test.go: "github.com/cyberphone/json-canonicalization/go/src/webpki.org/jsoncanonicalizer" ./tests/e2e_test.go:canonicalized, err := jsoncanonicalizer.Transform(payload) ./pkg/verify/verify.go: "github.com/cyberphone/json-canonicalization/go/src/webpki.org/jsoncanonicalizer" ./pkg/verify/verify.go: canonicalized, err := jsoncanonicalizer.Transform(contents) ./pkg/types/entries.go: "github.com/cyberphone/json-canonicalization/go/src/webpki.org/jsoncanonicalizer" ./pkg/types/entries.go: return jsoncanonicalizer.Transform(canonicalEntry) ./pkg/api/entries.go: "github.com/cyberphone/json-canonicalization/go/src/webpki.org/jsoncanonicalizer" ./pkg/api/entries.go: canonicalized, err := jsoncanonicalizer.Transform(payload) ./pkg/pki/tuf/tuf.go: "github.com/cyberphone/json-canonicalization/go/src/webpki.org/jsoncanonicalizer" ./pkg/pki/tuf/tuf.go: return jsoncanonicalizer.Transform(marshalledBytes) ./pkg/pki/tuf/tuf.go: return jsoncanonicalizer.Transform(marshalledBytes) jas@kaka:~/dpkg/golang-github-sigstore-rekor$ How would I force it to use your webpki.org namespace instead, simply patch all these occurances? Is is acceptable to patch upstream Go code to use other dependencies for Debian? I haven't done this with any package, so some assistance is appreciated. For reference my rekor package lives here: https://salsa.debian.org/jas/golang-github-sigstore-rekor Is this approach really scalable? Say 100 other upstream projects end up using cyberphone namespace, then Debian has to carry patches to change namespace for all of them, which is a lot of manual work. Once I can build your package, I can experiment with using it instead of my variant that lives here (failing license and lintian checks): https://salsa.debian.org/go-team/packages/golang-github-cyberphone-json-canonicalization https://salsa.debian.org/jas/golang-github-cyberphone-json-canonicalization/-/pipelines Hmm. Thinking out loud, perhaps a simpler compromise is to use your packaging but use the upstream namespace instead of changing it to golang-webpki-org-jsoncanonicalizer and webpki.org/jsoncanonicalizer namespace? Then no dependency will require patches. /Simon signature.asc Description: PGP signature
Bug#1060826: [Debian-on-mobile-maintainers] ITP: Mousai: Identify songs in seconds
Hi Chris, Le 15/01/2024 à 05:04, Chris Talbot a écrit : Package: wnpp Severity: wishlist Owner: Chris Talbot * Package name: mousai Version : 0.7.6 Upstream Author : Dave Patrick Caberto * URL : https://github.com/SeaDve/Mousai * License : GPL 3.0+ Programming Lang: Rust Description : Identify songs in seconds Mousai is an app that allows you to identify a song after listening to it in the microhpone. This package will be maintained by the Mobian team. Mousai being a GNOME Circle app, I believe the GNOME team would be a better fit for it. Cheers, Arnaud
