Bug#1068136: Bug#1069368: Updating golang-github-golang-protobuf-1-5 to fix FTBFS
On Sun, Apr 21, 2024 at 10:03 AM Mathias Gibbens wrote: > > On Sat, 2024-04-20 at 22:40 +0800, Shengjing Zhu wrote: > > On Sat, Apr 20, 2024 at 10:28 PM Mathias Gibbens wrote: > > > > > > Hi Anthony, > > > > > > A few weeks ago you uploaded a new version of golang-google-protobuf > > > to unstable which caused a FTBFS in golang-github-golang-protobuf-1-5 > > > v1.5.3 [1,2,3]. This has been blocking the transition of various golang > > > packages from unstable to testing. > > > > > > I've verified that v1.5.4 of golang-github-golang-protobuf-1-5 builds > > > fine on my amd64 system. `build-rdeps golang-github-golang-protobuf-1- > > > 5-dev` identifies 219 rdeps in main, so I haven't kicked off a `ratt` > > > run testing for any build regressions with the newer version yet. > > > > > > > This is a known regression in 1.5.3, see > > https://github.com/golang/protobuf/issues/1596#issuecomment-1981208282 > > Since that appears to be the only change in v1.5.4, would there be > any concerns with uploading that version to unstable? This breakage is > starting to cause FTBFS bugs to be filed against affected packages, > such as hugo (#1069371). > > Mathias Hi Reinhard, Mathias and Shengjing, Thank you for bringing this to my attention, and sorry for my late response! Thank you also for your detailed investigation! Very much appreciated! I don't see any concern uploading v1.5.4 especially how it fixes the regression and FTBFS with v1.5.3, and I'll be uploading golang-github-golang-protobuf-1-5 1.5.4-1 very shortly. Cheers, Anthony
Bug#1067684: ITP: goda -- Go Dependency Analysis toolkit
Package: wnpp
Severity: wishlist
Owner: Anthony Fok
* Package name: goda
Version : 0.5.7-1
Upstream Author : Egon Elbre
* URL : https://github.com/loov/goda
* License : Expat
Programming Lang: Go
Description : Go Dependency Analysis toolkit
Goda is a Go dependency analysis toolkit. It contains tools to figure
out what your program is using.
.
Cool things it can do:
.
# All of the commands should be run in the cloned repository.
git clone https://github.com/loov/goda && cd goda
.
# draw a graph of packages in github.com/loov/goda
goda graph "github.com/loov/goda/..." | dot -Tsvg -o graph.svg
.
# draw a dependency graph of github.com/loov/goda and dependencies
goda graph -cluster -short "github.com/loov/goda:all" | dot -Tsvg -o
graph.svg
.
# list direct dependencies of github.com/loov/goda
goda list "github.com/loov/goda/...:import"
.
# list dependency graph that reaches flag package, including std
goda graph -std "reach(github.com/loov/goda/...:all, flag)" | dot -Tsvg -o
graph.svg
.
# list packages shared by github.com/loov/goda/pkgset and
github.com/loov/goda/cut
goda list "shared(github.com/loov/goda/pkgset:all,
github.com/loov/goda/cut:all)"
.
# list packages that are only imported for tests
goda list "github.com/loov/goda/...:+test:all - github.com/loov/goda/...:all"
.
# list packages that are imported with `purego` tag
goda list -std "purego=1(github.com/loov/goda/...:all)"
.
# list packages that are imported for windows and not linux
goda list "goos=windows(github.com/loov/goda/...:all) -
goos=linux(github.com/loov/goda/...:all)"
.
# list how much memory each symbol in the final binary is taking
goda weight -h $GOPATH/bin/goda
.
# show the impact of cutting a package
goda cut ./...:all
.
# print dependency tree of all sub-packages
goda tree ./...:all
.
# print stats while building a go program
go build -a --toolexec "goda exec" .
.
# list dependency graph in same format as "go mod graph"
goda graph -type edges -f '{{.ID}}{{if .Module}}{{with
.Module.Version}}@{{.}}{{end}}{{end}}' ./...:all
.
How it differs from go list or go mod
.
go list and go mod are tightly integrated with Go and can answer simple
queries with compatibility. They also serves as good building blocks for
other tools.
.
goda is intended for more complicated queries and analysis. Some of the
features can be reproduced by format flags and scripts. However, this
library aims to make even complicated analysis fast.
.
Also, goda can be used together with go list and go mod.
Reasons for packaging:
- Recommended by Dominik Honnef, upstream author of golang-honnef-go-tools,
when he removed cmd/rdeps which, like dh-make-golang, also used
golang.org/x/tools/refactor/importgraph
- Potential solution to fix and improve "dh-make-golang estimate"
Bug#1035321: parsing of 'git log' seems to break when commits are signed
On Sun, Apr 30, 2023 at 2:18 PM John Scott wrote: > > Package: dh-make-golang > Version: 0.6.0-2+b5 > Severity: normal > Control: block 1035318 by -1 > > It looks like dh-make-golang fails when the commits are signed, and this > makes me unable to package the rtltcp library: > > $ dh-make-golang make -type "library" github.com/bemasher/rtltcp > 2023/04/30 15:46:18 Starting "dh-make-golang v0.6.0 linux/amd64" > 2023/04/30 15:46:18 Downloading "github.com/bemasher/rtltcp/..." > 2023/04/30 15:46:21 Determining upstream version number > 2023/04/30 15:46:21 Could not create a tarball of the upstream source: get > package version from Git: parse last commit date: strconv.ParseInt: parsing > "gpg: Signature made Sun 30 Apr 2023 03:27:39 PM EDT\ngpg: > using RSA key 4AEE18F83AFDEB23\ngpg: Good signature from \"GitHub (web-flow > commit signing) \" [marginal]\ngpg: nore...@github.com: > Verified 120 signatures in the past 2 years. Encrypted\n 0 > messages.\ngpg: Warning: you have yet to encrypt a message to this key!\ngpg: > WARNING: This key is not certified with sufficiently trusted > signatures!\ngpg: It is not certain that the signature belongs to > the owner.\n 5DE3E0509C47EA3CF04A42D34AEE18F83AFDEB23\n1682882859": > invalid syntax > > If this is not a trivial fix, if anyone knows of a workaround so I can > do my packaging, that would be nice. > > -- System Information: > Debian Release: 12.0 > APT prefers testing-debug > APT policy: (500, 'testing-debug'), (500, 'testing'), (2, > 'unstable-debug'), (2, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386, arm64 > > Kernel: Linux 6.1.0-7-amd64 (SMP w/2 CPU threads; PREEMPT) > Kernel taint flags: TAINT_USER, TAINT_FIRMWARE_WORKAROUND > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages dh-make-golang depends on: > ii git 1:2.39.2-1.1 > ii git-buildpackage 0.9.30 > ii golang-any2:1.19~1 > ii libc6 2.36-8 > ii pristine-tar 1.50 > > Versions of packages dh-make-golang recommends: > ii golang-golang-x-tools 1:0.5.0+ds-1 > ii msmtp-mta [mail-transport-agent] 1.8.23-1 > > dh-make-golang suggests no packages. > > -- no debconf information Hi John, Thank you for your report, and I apologize for my late reply. I did some testing, and was initially unable to reproduce the bug you are seeing until I added "log.showSignature = true" to my global git config file. Please try running the command: git config --show-origin --show-scope --get-all log.showSignature and see if it outputs anything; for example: global file:/home/foka/.gitconfig true Such a setting would forcefully show signatures when running "git log", which dh-make-golang does in "git log --pretty=format:%ct -n1" to get a timestamp. It can be fixed in dh-make-golang by adding the --no-show-signature option to the git log call, which I'll be uploading in 0.7.0-1 in the not-too-distant future. Until a fix is uploaded, you may use the following command to remove the setting from your global git config, i.e. ~/.gitconfig: git config --global --unset log.showSignature and you shouldn't see that error again. Cheers, Anthony
Bug#872807: Bug #872807: dh-make-golang: Please find dependencies based on Homepage, too
I am sorry, I copied the wrong bug number and inadvertently closed this bug by mistake. My apologies! It has now been reopened. Thanks, Anthony
Bug#1065732: podman: Please "Recommends: containers-storage" so overlay driver is used by default
Package: podman Version: 4.9.3+ds1-1 Severity: normal X-Debbugs-Cc: f...@debian.org When I first got Podman installed a year ago, I felt it was running a lot slower than Docker for some reasons, and eventually came across this: Podman run/build is painfully slow compared to docker https://github.com/containers/podman/issues/13226 and indeed, `podman info` on my system showed: graphDriverName: vfs It turns out I did not install the "Suggested" containers-storage package which contains /usr/share/containers/storage.conf that sets "overlay" as the default driver. There is a similar discussion at: https://www.reddit.com/r/podman/comments/14dgdf8/how_can_i_figure_out_which_storage_driver_podman/ Eventually, I ran the following commands to remedy the situation: sudo apt install containers-storage rm -rf ~/.local/share/containers podman system reset After that, `podman info` shows: graphDriverName: overlay I propose promoting the dependency on the containers-storage package from "Suggests" to "Recommends", or even to "Depends", so that "overlay" is consistently chosen as the default storage driver which provides a much better overall experience for end users. For reference, in Fedora, podman "Requires: containers-common-extra" which in turns "Requires: containers-common" which provides /usr/share/containers/storage.conf where storage = "overlay" is set. Many thanks! Anthony Fok -- System Information: Debian Release: trixie/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.7-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages podman depends on: ii conmon 2.1.10+ds1-1 ii crun 1.14.1-1 ii golang-github-containers-common 0.57.4+ds1-2 ii libc62.37-15.1 ii libdevmapper1.02.1 2:1.02.196-1 ii libgpgme11t64 [libgpgme11] 1.18.0-4.1 ii libseccomp2 2.5.5-1 ii libsqlite3-0 3.45.1-1 ii libsubid41:4.13+dfsg1-4 ii runc 1.1.12+ds1-2 Versions of packages podman recommends: ii buildah1.33.5+ds1-4 ii catatonit 0.1.7-1+b1 ii dbus-user-session 1.14.10-4 ii passt 0.0~git20240220.1e6f92b-1 ii slirp4netns1.2.1-1 ii tini 0.19.0-1 ii uidmap 1:4.13+dfsg1-4 Versions of packages podman suggests: ii containers-storage 1.51.0+ds1-2 pn docker-compose ii iptables1.8.10-3 -- Configuration Files: /etc/cni/net.d/87-podman-bridge.conflist [Errno 13] Permission denied: '/etc/cni/net.d/87-podman-bridge.conflist' -- no debconf information
Bug#1064540: ITP: golang-github-makeworld-the-better-one-dither -- fast, correct image dithering library in Go
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-makeworld-the-better-one-dither Version : 2.4.0-1 Upstream Author : makeworld * URL : https://github.com/makeworld-the-better-one/dither * License : MPL-2.0 Programming Lang: Go Description : fast, correct image dithering library in Go dither is a library for dithering images in Go. It has many dithering algorithms built-in, and allows you to specify your own. Correctness is a top priority, as well as performance. It is designed to work well on its own, but also implements interfaces from the standard library, so that it can be integrated easily in a wide variety of situtations. . This library is uniquely correct from a math and quality perspective. It linearizes the image, and color comparisons are done with human luminance perception in mind (channel weighting). Few-to-no other libraries do this. . It supports images that make use of the alpha channel, AKA transparency. . Types of dithering supported: . * Random noise (in grayscale and RGB) * Ordered Dithering - Bayer matrix of any size (as long as dimensions are powers of two) - Clustered-dot - many different preprogrammed matrices - Some unusual horizontal or vertical line matrices - Yours? + Using PixelMapperFromMatrix, this library can dither using any matrix + If you need more freedom, PixelMapper can be used to implement any method of dithering that affects each pixel individually . * Error diffusion dithering - Simple 2D - Floyd-Steinberg, False Floyd-Steinberg - Jarvis-Judice-Ninke - Atkinson - Stucki - Burkes - Sierra/Sierra3, Sierra2, Sierra2-4A/Sierra-Lite - Steven Pigeon (https://hbfs.wordpress.com/2013/12/31/dithering/) - Yours? Custom error diffusion matrices can be used by the library. . More methods of dithering are being worked on, such as Riemersma, Yuliluoma, and blue noise. Reason for packaging: Needed by hugo (>= 0.123.0)
Bug#1061548: ITP: tippecanoe -- build vector tilesets from large collections of GeoJSON features
Package: wnpp Severity: wishlist Owner: Anthony Fok X-Debbugs-Cc: debian-de...@lists.debian.org, pkg-grass-de...@lists.alioth.debian.org, f...@debian.org * Package name: tippecanoe Version : 2.24.1 Upstream Contact: Erica Fischer https://github.com/felt/tippecanoe/issues * URL : https://github.com/felt/tippecanoe * License : BSD-2-Clause, etc. Programming Lang: C++ Description : build vector tilesets from large collections of GeoJSON features Tippecanoe builds vector tilesets from large (or small) collections of GeoJSON, FlatGeobuf, or CSV features. . The goal of Tippecanoe is to enable making a scale-independent view of your data, so that at any level from the entire world to a single building, you can see the density and texture of the data rather than a simplification from dropping supposedly unimportant features or clustering or aggregating them. . If you give it all of OpenStreetMap and zoom out, it should give you back something that looks like "All Streets" rather than something that looks like an Interstate road atlas. . If you give it all the building footprints in Los Angeles and zoom out far enough that most individual buildings are no longer discernable, you should still be able to see the extent and variety of development in every neighborhood, not just the largest downtown buildings. . If you give it a collection of years of tweet locations, you should be able to see the shape and relative popularity of every point of interest and every significant travel corridor. I intend to use Tippecanoe to generate vector map tiles for RiskProfiler.ca (OpenDRR platform) as part of my work at/for Geological Survey of Canada, Natural Resources Canada. I plan to maintain this package within the Debian GIS Team. Thanks!
Bug#1057403: fq: Please upgrade to fq 0.9.0 (resolves FTBFS with latest golang-golang-x-exp-dev)
Package: fq Version: 0.3.0-1+b4 Severity: serious Tags: ftbfs upstream Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: Daniel Milde , Anthony Fok Hi Daniel (and other fellow Debian Go Packaging Team members), First of all, thank you for packaging fq, a very useful tool indeed. There has been an API change to SortFunc (etc.) in golang.org/x/exp/slices, (backported from "slices" in go1.21) which breaks fq << 0.8.0; please see: * slices: new standard library package based on x/exp/slices https://github.com/golang/go/issues/57433 * x/exp/slices: "backport" slices.SortFunc https://github.com/golang/go/issues/61374 So, after my recently upload of golang-golang-x-exp-dev, fq 0.3.0-1 now fails to build from source (FTBFS). Fortunately, the issue has been fixed upstream. Please kindly package fq 0.9.0, specifying these dependencies with explicit versions: * golang-github-burntsushi-toml-dev (>= 1.3.2) * golang-golang-x-exp-dev (>= 0.0~git20230725.302865e) Many thanks! Cheers, Anthony Fok -- System Information: Debian Release: trixie/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-5-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fq depends on: ii libc6 2.37-12 fq recommends no packages. fq suggests no packages. -- no debconf information
Bug#1057224: ITP: golang-github-microsoft-dev-tunnels -- Dev Tunnels SDK
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-microsoft-dev-tunnels Version : 0.0.25-1 Upstream Author : Microsoft Corporation * URL : https://github.com/microsoft/dev-tunnels * License : Expat Programming Lang: Go Description : Dev Tunnels SDK (Go library) Dev tunnels allows developers to securely expose local web services to the Internet, control who has access, and easily & debug your web applications from anywhere. Learn more at https://aka.ms/devtunnels/docs Reason for packaging: Dependency of gh (>= 2.36.0)
Bug#1055441: ITP: golang-golang-x-telemetry -- Go Telemetry services and libraries
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-golang-x-telemetry Version : 0.0~git20231030.36630a2-1 Upstream Author : The Go Authors * URL : https://github.com/golang/telemetry * License : BSD-3-Clause Programming Lang: Go Description : Go Telemetry services and libraries This package from the https://go.googlesource.com/telemetry repository holds the Go Telemetry server code and libraries. Reason for packaging: Needed by gopls (golang-golang-x-tools)
Bug#1055417: ITP: golang-github-tdewolff-argp -- GNU command line argument parser (Go library)
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-tdewolff-argp Version : 0.0~git20231030.fa6c548-1 Upstream Author : Taco de Wolff * URL : https://github.com/tdewolff/argp * License : Expat Programming Lang: Go Description : GNU command line argument parser (Go library) The argp Go package provides a command-line argument parser following the GNU standard. . ./test -vo out.png --size 256 input.txt . with the following features: . * build-in help (-h and --help) message * scan arguments into struct fields with configuration in tags * scan into composite field types (arrays, slices, structs) * allow for nested sub commands . GNU command line argument rules: . * arguments are options when they begin with a hyphen - * multiple options can be combined: -abc is the same as -a -b -c * long options start with two hyphens: --abc is one option * option names are alphanumeric characters * options can have a value: -a 1 means that a has value 1 * option values can be separated by a space, equal sign, or nothing: -a1 - a=1 -a 1 are all equal * options and non-options can be interleaved * the argument -- terminates all options so that all following arguments are treated as non-options * a single - argument is a non-option usually used to mean standard in or out streams * options may be specified multiple times, only the last one determines its value * options can have multiple values: -a 1 2 3 means that a is an array/slice/struct of three numbers of value [1,2,3] . See also github.com/tdewolff/prompt for a command-line prompter. Reason for packaging: Needed by golang-github-tdewolff-minify >= 2.20.5
Bug#1053978: ITP: golang-github-rodaine-table -- Go CLI Table Generator
Package: wnpp
Severity: wishlist
Owner: Anthony Fok
* Package name: golang-github-rodaine-table
Version : 1.1.0-1
Upstream Author : Chris Roche
* URL : https://github.com/rodaine/table
* License : Expat
Programming Lang: Go
Description : Go CLI Table Generator
Go package table provides a convenient way to generate tabular output
of any data, primarily useful for CLI tools.
.
Features:
.
* Accepts all data types (string, int, interface{}, everything!) and
will use the String() string method of a type if available.
* Can specify custom formatting for the header and first column cells
for better readability.
* Columns are left-aligned and sized to fit the data, with customizable
padding.
* The printed output can be sent to any io.Writer, defaulting to
os.Stdout.
* Built to an interface, so you can roll your own Table implementation.
* Works well with ANSI colors (fatih/color
(https://github.com/fatih/color) in the example)!
* Can provide a custom WidthFunc to accomodate multi- and zero-width
characters (such as runewidth (https://github.com/mattn/go-runewidth))
Reason for packaging:
* indirect dependency of gh >= 2.36.0
* direct dependeny of golang-github-microsoft-dev-tunnels (to be packaged)
Bug#1051245: ITP: golang-github-bep-logg -- fast and structured logging package for Go
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-bep-logg Version : 0.2.0-1 Upstream Authors: TJ Holowaychuk, Bjørn Erik Pedersen * URL : https://github.com/bep/logg * License : Expat Programming Lang: Go Description : fast and structured logging package for Go This is a fork of the exellent Apex Log (https://github.com/apex/log) library. . Main changes: . * Trim unneeded dependencies. * Make Fields into a slice to preserve log order. * Split the old Interface in two and remove all but one Log method (see below). * This allows for lazy creation of messages in Log(fmt.Stringer) and ignoring fields added in LevelLoggers with levels below the Loggers. * The pointer passed to HandleLog is not safe to use outside of the current log chain, and needs to be cloned with Clone first if that's needed. . This is probably the very fastest structured log library when logging is disabled. Reason for packaging: a dependency of hugo (>= 0.114.0)
Bug#1040808: ITP: golang-github-hashicorp-terraform-config-inspect -- helper library for shallow inspection of Terraform configurations
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-hashicorp-terraform-config-inspect Version : 0.0~git20230614.f32df32-1 Upstream Author : HashiCorp, Inc. * URL : https://github.com/hashicorp/terraform-config-inspect * License : MPL-2.0 Programming Lang: Go Description : helper library for shallow inspection of Terraform configurations terraform-config-inspect is a helper library and CLI tool for extracting high-level metadata about Terraform modules from their source code. It processes only a subset of the information Terraform itself would process, and in return it's able to be broadly compatible with modules written for many different versions of Terraform. . The primary way to use this is as a Go library, but as a convenience it also contains a CLI tool called terraform-config-inspect that allows viewing module information in either a Markdown-like format or in JSON format. Reason for packaging: Needed by terraform-switcher (ITP: #1014440)
Bug#1038681: ITP: golang-github-bep-simplecobra -- simpler API for the popular Cobra CLI
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-bep-simplecobra Version : 0.3.2-1 Upstream Author : Bjørn Erik Pedersen * URL : https://github.com/bep/simplecobra * License : Expat Programming Lang: Go Description : simpler API for the popular Cobra CLI So, Cobra (https://github.com/spf13/cobra) is a Go CLI library with a feature set that's hard to resist for bigger applications (autocompletion, docs and man pages auto generation etc.). But it's also complex to use beyond the simplest of applications. This package was built to help rewriting Hugo's (https://github.com/gohugoio/hugo) commands package to something that's easier to understand and maintain. Reason for packaging: Needed by hugo v0.112.0 and up
Bug#1038680: ITP: golang-github-bep-helpers -- Go utils package with a less burdened name by @bep
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-bep-helpers Version : 0.4.0-1 Upstream Author : Bjørn Erik Pedersen * URL : https://github.com/bep/helpers * License : Expat Programming Lang: Go Description : Go utils package with a less burdened name by @bep Some helper packages with some helper code that Bjørn Erik Pedersen (@bep) has had a tendency to copy from project to project over the years, prompting him to consider some reuse and create this Go package. Reason for packaging: Needed by e.g. hugo v0.112.0 and up
Bug#1037958: ITP: golang-github-bep-mclib -- simple Go library to make it possible to run mkcert's main method
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-bep-mclib Version : 1.20400.20402-1 Upstream Author : The mkcert Authors; Bjørn Erik Pedersen * URL : https://github.com/bep/mclib * License : Expat Programming Lang: Go Description : simple Go library to make it possible to run mkcert main method This is a simple Go library to make it possible to run mkcert's (https://github.com/FiloSottile/mkcert) main method. . The script that updates the internal package does no logic changes to the source; it simply . 1. Renames the main package to internal. 2. Renames the main func to RunMain 3. Replaces any log.Fatal with panic to allow us to handle the errors. 4. Exports getCAROOT(). . For more advanced library usage, see this issue (https://github.com/FiloSottile/mkcert/issues/45). Reason for packaging: Needed by hugo 0.113.0 and up
Bug#1037022: rime-data-jyut6ping3: Words/Characters not sorted by frequency (vocabulary file missing)
Package: rime-data-jyut6ping3 Version: 0.0~git20230209.e0295fa-1 Severity: important Tags: patch X-Debbugs-Cc: f...@debian.org Recently, the Jyut6ping3 Cantonese input method became very awkward to use because the vocabularies (words and characters) are not sorted by frequency order. It turns out that, starting with upstream snapshot 0.0~git20230209.e0295fa (or thereabouts in early February 2023), upstream maintainers has switched from using the preset vocabulary file in /usr/share/rime-data/essay.txt (from the rime-essay package) to a Cantonese-specific vocabulary file in /usr/share/rime-data/essay-cantonese.txt which unfortunately was not installed in rime-data-jyut6ping3 0.0~git20230209.e0295fa-1. Installing /usr/share/rime-data/essay-cantonese.txt resolves the issue; see the attached install-essay-cantonese.patch. Cheers, Anthony Fok -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages rime-data-jyut6ping3 depends on: ii rime-data-cangjie5 0.0~git20210223.8dfad9e-3+b1 ii rime-data-emoji0.0~git20230219.68dc116-1 ii rime-data-loengfan 0.0~git20220303.987ac95-1 ii rime-data-luna-pinyin 0.0~git20230204.79aeae2-2 ii rime-data-stroke 0.0~git20230204.c8bc405-1 rime-data-jyut6ping3 recommends no packages. rime-data-jyut6ping3 suggests no packages. -- no debconf information diff --git a/debian/rime-data-jyut6ping3.install b/debian/rime-data-jyut6ping3.install index 5a9f221..79fb3e9 100644 --- a/debian/rime-data-jyut6ping3.install +++ b/debian/rime-data-jyut6ping3.install @@ -2,3 +2,4 @@ build/jyut6ping3* usr/share/rime-data/build/ jyut6ping3*.yaml usr/share/rime-data/ opencc usr/share/rime-data/ symbols_cantonese.yaml /usr/share/rime-data/ +essay-cantonese.txt /usr/share/rime-data/
Bug#1034432: ITP: golang-github-hashicorp-terraform-registry-address -- Go library to represent, compare and parse Terraform Registry address
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-hashicorp-terraform-registry-address Version : 0.2.0-1 Upstream Author : HashiCorp, Inc. * URL : https://github.com/hashicorp/terraform-registry-address * License : MPL-2.0 Programming Lang: Go Description : Go library to represent, compare and parse Terraform Registry address This Go module enables parsing, comparison and canonical representation of Terraform Registry (https://registry.terraform.io/) "provider" addresses (such as registry.terraform.io/grafana/grafana or hashicorp/aws) and "module" addresses (such as hashicorp/subnets/cidr). Reason for packaging: Needed by terraform (RFP - #808940)
Bug#1033467: unblock: golang-github-yuin-goldmark/1.5.4-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: golang-github-yuin-goldm...@packages.debian.org,
debian...@lists.debian.org, f...@debian.org
Control: affects -1 + src:golang-github-yuin-goldmark
Please unblock package golang-github-yuin-goldmark
[ Reason ]
golang-github-yuin-goldmark/1.5.4-1 contains two bug fixes:
* ARIA role attribute in Markdown content is not rendered
https://github.com/gohugoio/hugo/issues/10661
https://github.com/yuin/goldmark/issues/357
* Blockquote tag appears after HTML not ending with newline
https://github.com/yuin/goldmark/issues/361
and this version is specified in hugo/0.111.3-1 go.mod as its dependency.
[ Impact ]
If the unblock isn't granted, hugo/0.111.3-1 and other bug-fix uploads for
other packages would not be able to migrate Debian 12 bookworm.
[ Tests ]
I used ratt to test rebuild of all 193 packages that directly
or indirectly depend on golang-github-yuin-goldmark.
All 193 packages passed except for the following 5:
FAILED: dnscrypt-proxy (see buildlogs/dnscrypt-proxy_2.0.45+ds1-1)
FAILED: gitaly (see buildlogs/gitaly_13.4.6+dfsg1-2)
FAILED: nomad (see buildlogs/nomad_0.12.10+dfsg1-3)
FAILED: nomad-driver-podman (see buildlogs/nomad-driver-podman_0.1.0-2)
FAILED: golang-github-prometheus-common (see
buildlogs/golang-github-prometheus-common_0.15.0-2)
The first 4 (dnscrypt-proxy, gitaly, nomad, nomad-driver-podman)
currently FTBFS and were removed from testing/bookworm some time ago.
(I've just uploaded an NMU for dnscrypt-proxy as its FTBFS is trivial to
fix.)
The last one "golang-github-prometheus-common" failed because dose-ceve
(which ratt uses) incorrectly returned the version in stable/bullseye.
Rebuilding for golang-github-prometheus-common_0.39.0-2 manually with
the following command completes successfully:
sbuild --arch-all --dist=unstable --nolog \
golang-github-prometheus-common_0.39.0-2 \
--extra-package=../golang-github-yuin-goldmark-dev_1.5.4-1_all.deb
[ Risks ]
I must admit I did not know that golang-github-yuin-goldmark is marked
as a key package, but with the successful "ratt" rebuild of all affected
packages, as well as the minimal bug fixes that simply corrects its HTML
output, there is no risk in upgrading golang-github-yuin-goldmark from
1.5.3-1 to 1.5.4-1.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
unblock golang-github-yuin-goldmark/1.5.4-1
Many thanks!
Anthony Fok
diff -Nru golang-github-yuin-goldmark-1.5.3/debian/changelog
golang-github-yuin-goldmark-1.5.4/debian/changelog
--- golang-github-yuin-goldmark-1.5.3/debian/changelog 2023-01-23
07:12:53.0 -0700
+++ golang-github-yuin-goldmark-1.5.4/debian/changelog 2023-03-08
19:19:12.0 -0700
@@ -1,3 +1,9 @@
+golang-github-yuin-goldmark (1.5.4-1) unstable; urgency=medium
+
+ * New upstream version 1.5.4
+
+ -- Anthony Fok Wed, 08 Mar 2023 19:19:12 -0700
+
golang-github-yuin-goldmark (1.5.3-1) unstable; urgency=medium
* New upstream version 1.5.3
diff -Nru golang-github-yuin-goldmark-1.5.3/parser/html_block.go
golang-github-yuin-goldmark-1.5.4/parser/html_block.go
--- golang-github-yuin-goldmark-1.5.3/parser/html_block.go 2022-11-12
04:13:03.0 -0700
+++ golang-github-yuin-goldmark-1.5.4/parser/html_block.go 2023-02-02
05:02:21.0 -0700
@@ -149,7 +149,7 @@
}
}
if node != nil {
- reader.Advance(segment.Len() - 1)
+ reader.Advance(segment.Len() - util.TrimRightSpaceLength(line))
node.Lines().Append(segment)
return node, NoChildren
}
@@ -172,7 +172,7 @@
}
if htmlBlockType1CloseRegexp.Match(line) {
htmlBlock.ClosureLine = segment
- reader.Advance(segment.Len() - 1)
+ reader.Advance(segment.Len() -
util.TrimRightSpaceLength(line))
return Close
}
case ast.HTMLBlockType2:
@@ -211,7 +211,7 @@
}
}
node.Lines().Append(segment)
- reader.Advance(segment.Len() - 1)
+ reader.Advance(segment.Len() - util.TrimRightSpaceLength(line))
return Continue | NoChildren
}
diff -Nru golang-github-yuin-goldmark-1.5.3/README.md
golang-github-yuin-goldmark-1.5.4/README.md
--- golang-github-yuin-goldmark-1.5.3/README.md 2022-11-12 04:13:03.0
-0700
+++ golang-github-yuin-goldmark-1.5.4/README.md 2023-02-02 05:02:21.0
-0700
@@ -446,6 +446,8 @@
- [goldmark-embed](https://github.com/13rac1/goldmark-embed): Adds support for
rendering embeds from YouTube links.
- [goldmark-latex](https://github.com/soypat/goldmark-latex): A $\LaTeX$
renderer that can be passed to `goldmark.WithRenderer()`.
Bug#1033442: unblock: golang-go.opencensus/0.24.0-1
On Fri, Mar 24, 2023 at 3:33 PM Anthony Fok wrote: > ratt finds 89 packages with direct or indirect dependency on > golang-go.opencensus and is able to build all of them with > with golang-go.opencensus/0.24.0-1 smoothly with no hiccup. Clarification: Out of the 89 packages, 4 failed but not due to golang-go.opencensus: FAILED: cadvisor (see buildlogs/cadvisor_0.38.7+ds1-2) FAILED: golang-github-prometheus-common (see buildlogs/golang-github-prometheus-common_0.15.0-2) FAILED: nomad (see buildlogs/nomad_0.12.10+dfsg1-3) FAILED: nomad-driver-podman (see buildlogs/nomad-driver-podman_0.1.0-2) 3 of them, cadvisor, nomad and nomad-driver-podman are currently FTBFS in the archive and are not in "testing". As for golang-github-prometheus-common_0.15.0-2, ratt picked the wrong version in stable (bullseye) instead of 0.39.0-2 in sid. Apparently, ratt's dependency dose-ceve does not handle the multiple "same Package, different Version" entries in the source list and simply picks the first one: $ grep -A2 '^Package: golang-github-prometheus-common' \ /var/lib/apt/lists/deb.debian.org_debian_dists_sid_main_source_Sources Package: golang-github-prometheus-common Binary: golang-github-prometheus-common-dev Version: 0.15.0-2 -- Package: golang-github-prometheus-common Binary: golang-github-prometheus-common-dev Version: 0.39.0-2 So, while this erroneous sbuild command fails: sbuild --arch-all --dist=unstable --nolog \ golang-github-prometheus-common_0.15.0-2 \ --extra-package=../golang-go.opencensus-dev_0.24.0-1_all.deb the correct sbuild command pointing to the correct version in sid passes: sbuild --arch-all --dist=unstable --nolog \ golang-github-prometheus-common_0.39.0-2 \ --extra-package=../golang-go.opencensus-dev_0.24.0-1_all.deb So, yes, it is perfectly safe to upgrade golang-go.opencensus 0.23.0-4 to 0.24.0-1. Many thanks! Cheers, Anthony Fok
Bug#1033442: unblock: golang-go.opencensus/0.24.0-1
On Fri, Mar 24, 2023 at 3:33 PM Anthony Fok wrote:
> [ Checklist ]
> [x] all changes are documented in the d/changelog
> [x] I reviewed all changes and I approve them
> [x] attach debdiff against the package in testing
Sorry, I forgot to actually attach the debdiff file. Attached in this
follow-up message. :-)
Cheers,
Anthony Fok
diff -Nru golang-go.opencensus-0.23.0/debian/changelog golang-go.opencensus-0.24.0/debian/changelog
--- golang-go.opencensus-0.23.0/debian/changelog 2023-01-04 15:26:48.0 -0700
+++ golang-go.opencensus-0.24.0/debian/changelog 2023-03-09 02:33:15.0 -0700
@@ -1,3 +1,14 @@
+golang-go.opencensus (0.24.0-1) unstable; urgency=medium
+
+ * New upstream version 0.24.0
+ * Reorder fields in debian/control and debian/copyright
+ * Bump versioned dependencies as per go.mod:
+- golang-github-google-go-cmp-dev (>= 0.5.3)
+- golang-github-stretchr-testify-dev (>= 1.8.1)
+- golang-google-grpc-dev (>= 1.33.2)
+
+ -- Anthony Fok Thu, 09 Mar 2023 02:33:15 -0700
+
golang-go.opencensus (0.23.0-4) unstable; urgency=medium
* Team upload
diff -Nru golang-go.opencensus-0.23.0/debian/control golang-go.opencensus-0.24.0/debian/control
--- golang-go.opencensus-0.23.0/debian/control 2023-01-02 09:30:05.0 -0700
+++ golang-go.opencensus-0.24.0/debian/control 2023-03-09 02:32:16.0 -0700
@@ -1,36 +1,36 @@
Source: golang-go.opencensus
+Section: golang
+Priority: optional
Maintainer: Debian Go Packaging Team
Uploaders: Stephen Gelman ,
Anthony Fok
-Section: golang
-Testsuite: autopkgtest-pkg-go
-Priority: optional
+Rules-Requires-Root: no
Build-Depends: debhelper-compat (= 13),
dh-golang,
golang-any,
- golang-github-google-go-cmp-dev (>= 0.3.0),
+ golang-github-google-go-cmp-dev (>= 0.5.3),
golang-github-golang-groupcache-dev,
- golang-github-stretchr-testify-dev (>= 1.4.1),
+ golang-github-stretchr-testify-dev (>= 1.8.1),
golang-golang-x-net-dev,
- golang-google-grpc-dev (>= 1.20.1),
+ golang-google-grpc-dev (>= 1.33.2),
golang-github-golang-protobuf-1-3-dev
+Testsuite: autopkgtest-pkg-go
Standards-Version: 4.6.2
Vcs-Browser: https://salsa.debian.org/go-team/packages/golang-go.opencensus
Vcs-Git: https://salsa.debian.org/go-team/packages/golang-go.opencensus.git
Homepage: https://github.com/census-instrumentation/opencensus-go
-Rules-Requires-Root: no
XS-Go-Import-Path: go.opencensus.io
Package: golang-go.opencensus-dev
Architecture: all
Multi-Arch: foreign
-Depends: ${misc:Depends},
- golang-github-google-go-cmp-dev (>= 0.3.0),
+Depends: golang-github-google-go-cmp-dev (>= 0.5.3),
golang-github-golang-groupcache-dev,
- golang-github-stretchr-testify-dev (>= 1.4.1),
+ golang-github-stretchr-testify-dev (>= 1.8.1),
golang-golang-x-net-dev,
- golang-google-grpc-dev (>= 1.20.1),
- golang-github-golang-protobuf-1-3-dev | golang-github-golang-protobuf-1-5-dev
+ golang-google-grpc-dev (>= 1.33.2),
+ golang-github-golang-protobuf-1-3-dev | golang-github-golang-protobuf-1-5-dev,
+ ${misc:Depends}
Description: Stats collection and distributed tracing framework
OpenCensus Go is a Go implementation of OpenCensus, a toolkit for
collecting application performance and behavior monitoring data.
diff -Nru golang-go.opencensus-0.23.0/debian/copyright golang-go.opencensus-0.24.0/debian/copyright
--- golang-go.opencensus-0.23.0/debian/copyright 2022-12-31 17:30:47.0 -0700
+++ golang-go.opencensus-0.24.0/debian/copyright 2023-03-09 02:30:39.0 -0700
@@ -1,9 +1,9 @@
Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
-Upstream-Name: go.opencensus.io
Source: https://github.com/census-instrumentation/opencensus-go
+Upstream-Name: go.opencensus.io
Files: *
-Copyright: 2017-2019 OpenCensus
+Copyright: 2017-2022 OpenCensus
License: Apache-2.0
Files: debian/*
@@ -23,6 +23,6 @@
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
- .
+Comment:
On Debian systems, the complete text of the Apache version 2.0 license
can be found in "/usr/share/common-licenses/Apache-2.0".
diff -Nru golang-go.opencensus-0.23.0/examples/derived_gauges/derived_gauge.go golang-go.opencensus-0.24.0/examples/derived_gauges/derived_gauge.go
--- golang-go.opencensus-0.23.0/examples/derived_gauges/derived_gauge.go 2021-02-12 09:50:36.0 -0700
+++ golang-go.opencensus-0.24.0/examples/derived_gauges/derived_gauge.go 2022-11-03 14:13:50.0 -0600
@@ -20,7 +20,7 @@
// items. Consumer randomly consumes 1-5 items in each attempt. It then sleeps randomly
// between 1-10 seconds
Bug#1033442: unblock: golang-go.opencensus/0.24.0-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: golang-go.opencen...@packages.debian.org, debian...@lists.debian.org, f...@debian.org Control: affects -1 + src:golang-go.opencensus Please unblock package golang-go.opencensus/0.24.0-1 packer/1.6.6+ds1-7 in testing has an RC bug (#1032525) and is scheduled for autoremoval on 2023-04-06. The fix was uploaded by its maintainer Shengjing Zhu in packer/1.6.6+ds2-1 on 2023-03-13, but it is currently prevented from migrating to testing to due to being blocked by its indirect dependency on golang-go.opencensus. My apologies for my untimely upload of golang-go.opencensus/0.24.0-1 on 2023-03-09, assuming that it would enter testing automatically after 20 days, not knowing that it is a key package that would require a manual unblock. Risks of upgrading from 0.23.0 to 0.24.0 is minimal, as the changes consist of minor bug fixes with a small addition to the API. ratt finds 89 packages with direct or indirect dependency on golang-go.opencensus and is able to build all of them with with golang-go.opencensus/0.24.0-1 smoothly with no hiccup. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock golang-go.opencensus/0.24.0-1 Thanks for your help! Cheers, Anthony Fok
Bug#1032692: ITP: gitleaks -- protect and discover secrets using Gitleaks
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: gitleaks Version : 8.16.0-1 Upstream Author : Zachary Rice * URL : https://github.com/gitleaks/gitleaks * License : Expat Programming Lang: Go Description : protect and discover secrets using Gitleaks Gitleaks is a SAST tool for **detecting** and **preventing** hardcoded secrets like passwords, api keys, and tokens in git repos. Gitleaks is an **easy-to-use, all-in-one solution** for detecting secrets, past or present, in your code.
Bug#940444: ITA: golang-gopkg-h2non-filetype.v1
Control: retitle -1 ITA: golang-gopkg-h2non-filetype.v1 Control: owner -1 ! Hello, I intend to adopt this package because a newer version of golang-gopkg-h2non-filetype.v1 (now known as github.com/h2non-filetype v1.1.3) is needed by gitleaks. Thank you Alexandre for your great work in creating and maintaining this package! Cheers, Anthony
Bug#1032574: ITP: golang-github-fatih-semgroup -- like errgroup/waitgroup, but only runs a maximum of tasks at any time
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-fatih-semgroup Version : 1.2.0-1 Upstream Author : Fatih Arslan * URL : https://github.com/fatih/semgroup * License : BSD-3-clause Programming Lang: Go Description : like errgroup/waitgroup, but only runs a maximum of tasks at any time semgroup provides synchronization and error propagation, for groups of goroutines working on subtasks of a common task. It uses a weighted semaphore implementation to make sure that only a number of maximum tasks can be run at any time. . Unlike golang.org/x/sync/errgroup, it doesn't return the first non-nil error, rather it accumulates all errors and returns a set of errors, allowing each task to fullfil their task. Reason for packaging: Needed by gitleaks
Bug#1032573: ITP: golang-github-petar-dambovaliev-aho-corasick -- efficient string matching in Golang via the Aho-Corasick algorithm
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-petar-dambovaliev-aho-corasick Version : 0.0~git20211021.5ab2d92-1 Upstream Author : Petar Dambovaliev * URL : https://github.com/petar-dambovaliev/aho-corasick * License : Expat Programming Lang: Go Description : efficient string matching in Golang via the Aho-Corasick algorithm This package provides efficient string matching in Golang via the Aho-Corasick algorithm. . ×20 faster than github.com/cloudflare/ahocorasick and ×3 faster than github.com/anknown/ahocorasick . Memory consuption is a eighth of github.com/cloudflare/ahocorasick and half of github.com/anknown/ahocorasick . This library is heavily inspired by BurntSushi’s fast implementation of Aho-Corasick in Rust; see https://github.com/BurntSushi/aho-corasick Reason for packaging: Needed by gitleaks
Bug#1032535: ITP: golang-github-hashicorp-golang-lru-v2 -- Golang LRU cache (v2 with support for generics)
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-hashicorp-golang-lru Version : 2.0.1-1 Upstream Author : HashiCorp, Inc. * URL : https://github.com/hashicorp/golang-lru * License : MPL-2.0 Programming Lang: Go Description : Golang LRU cache (v2 with support for generics) This provides the lru package which implements a fixed-size thread-safe LRU cache. It is based on the cache in Groupcache. v2 adds support for generics. Reason for packaging: Needed by golang-github-bep-lazycache(-dev), which in turn is needed by hugo (>= 0.111.0).
Bug#1032527: ITP: golang-github-bep-lazycache -- Thread-safe in-memory LRU cache with non-blocking cache priming on cache misses (Go library)
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-bep-lazycache Version : 0.2.0-1 Upstream Author : Bjørn Erik Pedersen * URL : https://github.com/bep/lazycache * License : Expat Programming Lang: Go Description : Thread-safe in-memory LRU cache with non-blocking cache priming on cache misses (Go library) Lazycache is a simple thread safe in-memory LRU cache. Under the hood it leverages the great simpleru package in golang-lru, with its exellent performance. One big difference between golang-lru and this library is the GetOrCreate method, which provides: . * Non-blocking cache priming on cache misses. * A guarantee that the prime function is only called once for a given key. * The cache's RWMutex is not locked during the execution of the prime function, which should make it easier to reason about potential deadlocks. . Other notable features: . * The API is generic * The cache can be resized while running. * When the number of entries overflows the defined cache size, the least recently used item gets discarded (LRU). Reason for packaging: Needed by hugo (>= 0.111.0)
Bug#1032524: ITP: golang-github-gitleaks-go-gitdiff -- Go library for parsing and applying patches created by Git
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-gitleaks-go-gitdiff Version : 0.8.0-1 Upstream Author : Gitleaks * URL : https://github.com/gitleaks/go-gitdiff * License : Expat Programming Lang: Go Description : Go library for parsing and applying patches created by Git go-gitdiff is a Go library for parsing and applying patches generated by git diff, git show, and git format-patch. It can also parse and apply unified diffs generated by the standard diff tool. . It supports standard line-oriented text patches and Git binary patches, and aims to parse anything accepted by the git apply command. Reason for packaging: A dependency of gitleaks
Bug#1026200: Please package LilyPond 2.24.0 if possible
On Sun, Jan 29, 2023 at 2:37 AM Jonas Hahnfeld wrote:
> Thank you for your work! Unfortunately the package is missing two other
> major changes in 2.24.0: the Scheme files (.scm) should be byte-
> compiled for reasonable performance (which will depend on the
> architecture, to some degree, so maybe merge lilypond and -data?) and
> text fonts must be shipped separately. Please have a look here:
> https://lilypond.org/doc/v2.24/Documentation/changes/index.html#notes-for-source-compilation-and-packagers
>
> ...
>
> It turns out, this should be pretty straightforward: Just add
> dependencies to fonts-urw-base35 and (optionally, as a suggest?) to
> fonts-texgyre. They should be shipping the .otf versions, but it's
> probably best to verify with $ lilypond -dshow-available-fonts.
Hi Jonas,
Sorry for my late reply, which I should have done three weeks ago.
Thank you so much for the tips, for pointing me to the exact
documentation, and for finding out the actual package names for the
fonts that I need to depend on or recommend. This accumulated in the
earlier 2.24.0-3 Debian package release
lilypond (2.24.0-3) unstable; urgency=medium
* Remove doc packages unneeded dependency on install-info.
Thanks to Hilmar Preuße for the explanation! (Closes: #1012424)
* debian/rules: Run "$(MAKE) bytecode" and "$(MAKE) install-bytecode"
The Scheme files (.scm) should be byte-compiled for reasonable performance.
See the "Notes for source compilation and packagers" section
in https://lilypond.org/doc/v2.24/Documentation/changes/index.html
Thanks to Jonas Hahnfeld for telling me about this major change in 2.24.0!
* debian/lilypond.install: Add "usr/lib" to install the bytecode objects
/usr/lib/${DEB_HOST_MULTIARCH}/lilypond/2.24.0/ccache/lily/*.go
* Exclude the bytecode objects from dh_dwz and dh_strip to avoid errors
* Add Lintian overrides for bytecode objects for tags
binary-from-other-architecture, unstripped-binary-or-object
and shared-library-lacks-prerequisites
* Add "Depends: fonts-urw-base35" and "Recommends: fonts-texgyre"
These fonts were shipped with lilypond-fonts in 2.22 but removed in 2.24.
Thanks to Jonas Hahnfeld for finding the names of the needed font packages!
-- Anthony Fok Fri, 03 Feb 2023 18:30:57 -0700
Cheers,
Anthony
Bug#1026200: Please package LilyPond 2.24.0 if possible
Hi Jonas, On Wed, Jan 25, 2023 at 2:44 PM Jonas Hahnfeld wrote: > Thanks for pushing to get guile-2.2 back into Debian and LilyPond > 2.24.0 packaged for Debian Bookworm, much appreciated. Regarding > maintenance of Guile 2.2, we are probably in this together since our > official binaries use it as well... Many thanks to Rob Browning for his blessings, and to the Debian FTP Masters for asking me for more details, and let guile-2.2 back into Debian 12 bookworm. And thank you for offering to help with Guile 2.2 maintenance just in case any problem arises! I really hope LilyPond 2.26.0 and the rest of the ecosystem (e.g. on Windows platform) will be ready for Guile 3.0 really soon. And... lilypond 2.24.0-1 has entered Debian! Though I already found a bug when upgrading lilypond-doc due to /usr/share/info/lilypond symlink conflict, my own fault for not testing it thoroughly enough before upload. Thanks to excellent commit messages in LilyPond, by Kevin Barry in this case, I was able to find out the problem and fix it in a jiffy: we had been running (in debian/rules) both "$(MAKE) install-doc" and "$(MAKE) install-info", not knowing that it is not only an unnecessary duplication, but also install-info's behaviour changed. Building 2.24.0-2 now, and keeping my fingers crossed. :-) > Another question for planning would be regarding Debian's freeze: What > would be the last date that you could possibly pick up a bug fix > release 2.24.1 of LilyPond? There are no concrete plans yet, but if you > say that it is possible and somehow fits the schedule, we might go for > it. Great question! I'm not entirely sure! You likely know about about freeze schedule from https://release.debian.org/bookworm/freeze_policy.html but how it would exactly happen is a bit hard to say; there is always uncertainty, but here is my interpretation: According to that page, since the Soft Freeze starts on 2023-02-12, I would say having 2.24.1 released before 2023-02-05 would be the safest bet, giving me a day or two of leeway to get it built, tested and uploaded, and then 5 days for migration to testing/bookworm before 2023-02-12. Though maybe if I were to set "urgency=high" in debian/changelog, the delay is supposedly reduced to 2 days, so perhaps 2023-02-08? That said, since 2023-02-12 is a "Soft Freeze", bug fix releases can still go after 2023-02-12, though the delay to testing migration becomes 10 days regardless of the urgency setting, so perhaps 2023-02-28 is the absolute latest for a bug fix release to make it into bookworm before the 2023-03-12 Hard Freeze? That said, bug fixes after 2023-03-12 is still possible (with a minimum 20-day delay for migration to bookworm), but the lilypond Debian package currently does not have any autopkgtest yet, so that would require a manual review and unblock from the Release Managers. I suppose I could try to add an autopkgtest for LilyPond by trying to run "make test" but hopefully using the existing /usr/bin/lilypond binary instead of recompiling the whole thing from source? (Though that's a possibility too...) That might remove the need for manual review. I'm not sure. Failing that, there will be "bookworm-backports" after the Debian 12 is released where we could backport future bug fixes. Something like that? Thank you so much for your work on LilyPond! It's always exciting to have a new release as an end user, and it is amazing the amount of dedication and great work that you and the rest of the LilyPond development team put into such a complicated yet immensely useful piece of software. Kudos to you all! Cheers, Anthony
Bug#1029721: ITP: golang-github-nrdcg-namesilo -- Go library for accessing the Namesilo API
Package: wnpp
Severity: wishlist
Owner: Anthony Fok
* Package name: golang-github-nrdcg-namesilo
Version : 0.2.1-1
Upstream Author : The Natural Reserve of DNS Clients in Go.
* URL : https://github.com/nrdcg/namesilo
* License : MPL-2.0
Programming Lang: Go
Description : Go library for accessing the Namesilo API
namesilo is a Go client library for accessing the Namesilo API.
.
Example
.
package main
.
import (
"fmt"
"log"
.
"github.com/nrdcg/namesilo"
)
.
func main() {
transport, err := namesilo.NewTokenTransport("1234")
if err != nil {
log.Fatal(err)
}
.
client := namesilo.NewClient(transport.Client())
.
params := {
Amount:"100",
PaymentID: "acbd",
}
.
funds, err := client.AddAccountFunds(params)
if err != nil {
log.Fatal(err)
}
.
fmt.Println(funds)
}
Reason for packaging:
golang-github-nrdcg-namesilo-dev is an unpackaged dependency
of golang-github-xenolf-lego, a Let's Encrypt client written in Go.
Bug#1029644: ITP: golang-github-perimeterx-marshmallow -- flexible and performant JSON unmarshalling in Go
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-perimeterx-marshmallow Version : 1.1.4-1 Upstream Author : PerimeterX * URL : https://github.com/perimeterx/marshmallow * License : Expat Programming Lang: Go Description : flexible and performant JSON unmarshalling in Go Marshmallow package provides a simple API to perform flexible and performant JSON unmarshalling in Go. . Marshmallow specializes in dealing with **unstructured struct** - when some fields are known and some aren't, with zero performance overhead nor extra coding needed. While unmarshalling, marshmallow allows fully retaining the original data and access it via a typed struct and a dynamic map. Reason for packaging: Needed by golang-github-getkin-openapi (>= 0.113.0), which in turn is needed by a future version of hugo.
Bug#1026200: Please package LilyPond 2.24.0 if possible
On Sun, Jan 22, 2023 at 8:00 PM Rob Browning wrote: > > Anthony Fok writes: > > > Thank you so much for Cc'ing Rob regarding Guile-2.2. > > > > Rob, as you can see, there is a real need for Guile 2.2 for LilyPond > > 2.24.0 (December 2022), this coming from LilyPond's Core Developer > > Jonas Hahnfeld and "Factotum" and Jean Abou Samra. If it is OK with > > you, Rob, I would be more than happy to adopt guile-2.2 and maintain > > it for the entire lifetime of Debian 12 (bookworm), and hopefully by > > Debian 13 (trixie), LilyPond will be ready for guile-3.0. :-)\ > > Many thanks for your understanding! Hello Rob, Thank you so much for your reply! > I'd be very hesitant to include Guile 2.2 in bookworm since I believe > it's explicitly not supported upstream and hasn't had a single commit > in over two years. > > If there's any chance LilyPond will support something newer in a > reasonable time-frame, I might suggest just waiting, and then > introducing the new version via backports. > > But I don't really understand the situation and constraints. The LilyPond development team actually values Debian very much, and has specifically contacted me (the current maintainer of the LilyPond package), and carefully planned and timed the LilyPond v2.24.0 release to be just right for the Debian 12 bookworm release. Unfortunately, Guile-3.0 is still problematic for the just-released LilyPond v2.24.0, especially concerning cross-platform compatibility, so much so that the LilyPond development team is pleading us to keep Guile-2.2 in Debian just a while longer. > That said, I won't oppose reintroducing 2.2, as long as I'm not > responsible for it, and you're willing to herd all the cats to get it > removed again as soon as possible. That was a good bit of work I'd > prefer not to repeat. Thank you so much for your understanding! Yes, I'll be more than willing to take on the responsibility of getting guile-2.2 removed from Debian 13 trixie as soon as LilyPond is ready. Your hard work in getting guile-2.2 removed from bookworm means that almost all other software packages have migrated to guile-3.0, with lilypond being the only odd one out. Many thanks! Anthony
Bug#1029576: ITP: golang-github-hexops-gotextdiff -- Unified text diffing in Go (copy gopls internal diffing)
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-hexops-gotextdiff Version : 1.0.3-1 Upstream Author : Hexops * URL : https://github.com/hexops/gotextdiff * License : BSD-3-clause Programming Lang: Go Description : Unified text diffing in Go (copy of gopls internal diffing) gotextdiff is a copy of the Go text diffing packages that the official Go language server gopls uses internally to generate unified diffs. . If you've previously tried to generate unified text diffs in Go (like the ones you see in Git and on GitHub), you may have found github.com/sergi/go-diff which is a Go port of Neil Fraser's google-diff-match-patch code - however it does not support unified diffs. . This is arguably one of the best (and most maintained) unified text diffing packages in Go as of at least 2020. . (All credit goes to the Go authors (http://tip.golang.org/AUTHORS), I am merely re-publishing their work so others can use it.) Reason for packaging: Required by golang-github-alecthomas-assert 2.2.0, which is required by golang-github-alecthomas-chroma-v2 2.4.0, which in turn is required by hugo 0.107.0 and up.
Bug#1022001: libwebp: Please package new upstream release 1.2.4
On Tue, Oct 18, 2022 at 1:15 PM Boyuan Yang wrote: > Also, the package libavif I maintain has libsharpyuv as a new build- > dependency, which is provided by src:libwebp in the new release. Please also > consider providing the libsharpyuv library. Thanks! (This has already been communicated to Boyuan, but for the record on Debian BTS...) It turns out that libsharpyuv is not yet an installable standalone library in libwebp v1.2.4. From the git log for commit 29cc95ce4cfeae88de13f44c43d8e73ffb782f79 leading up to v1.2.3: It's self contained apart from a dependency on src/webp/types.hand src/dsp/cpu.h For now it's only set up as an internal library, not an installable one. Webp doesn't depend on it yet, the code is only duplicated. libsharpyuv.so as an installable library appears in libwebp 1.3.0, but which I'm not packaging for bookmark, just to be safe; maybe we'll get it to bookmark-backports in the future: - 12/16/2022: version 1.3.0 This is a binary compatible release. * add libsharpyuv, which exposes -sharp_yuv/config.use_sharp_yuv functionality to other libraries; libwebp now depends on this library * major updates to the container and lossless bitstream docs (#448, #546, #551) * miscellaneous warning, bug & build fixes (#576, #583, #584): Cheers, Anthony
Bug#1026231: debian-policy: document droppage of support for legacy locales
On Fri, Jan 20, 2023 at 10:15 AM Adam Borowski wrote: > > On Fri, Jan 20, 2023 at 03:57:17PM +0200, Wouter Verhelst wrote: > > On Thu, Jan 19, 2023 at 11:47:42AM +, Simon McVittie wrote: > > If the PRC government *requires* a non-UTF-8 encoding for things sold to > > them, we would be doing our users who want to sell a product containing > > Debian to the PRC government a disservice by dropping support for it > > altogether. > > It appears to me they require the character _set_ but not encoding: ie, > that all glyphs can be displayed, they can be entered from keyboard, etc. > The standard talks a lot about font support, etc. Hi Adam, You are correct indeed. Yes, they worry more about the correct coverage of characters, especially those that were added in 2022 corresponding to the latest ISO/IEC 10646 standard. That said, they do require the ability to open, edit, and convert GB18030-encoded files, but that is at the iconv() / ICU / application level, but, like you said, they are NOT enforcing the use of zh_CN.GB18030 as system locale. (I now stand corrected.) Incidentally, they have published three pre-recorded webinars thus far, and I have reuploaded them to YouTube here for easier access for the rest of the world: https://www.youtube.com/watch?v=6gByuPXth7s=PLWCc17-QBkRjwhRfvCpxM8ez3b0qWO59a I have yet to figure out how to add automatic Chinese subtitles and to have it translated to English. Maybe some day. :-) > > We don't have to ensure it works perfectly out of the box; just that > > support is achievable with a reasonable amount of work. > > Our installer doesn't allow choosing such a locale, thus if indeed the > encoding not character set is legally required, then we'd need to change > so before the release. > > But I don't expect that to be the case -- a few years ago I played with > Deepin and don't remember any weird encoding being used. It would be good > to either check again, or ask one of their maintainers. Indeed, and that is what friends on #debian-zh IRC channel are trying to tell me, and I have personally confirmed that not only Deepin, but also Red Flag, openKylix, Ubuntu Kylix all use zh_CN.UTF-8 as the default system locale (see my one of the really long-winded response in this thread for details. So you are indeed correct, and I stand corrected too. Sorry for the false alarm! My mindset was still living in 2002 when zh_CN.GB18030 was assumed to be a requirement by the industry, but apparently all distros have switched over to zh_CN.UTF-8 by default. Debian does still support zh_CN.GB18030 with KDE, LXDE, LXQt, Cinnamon, MATE, etc., but crashes with GNOME 43 and XFCE at the moment (at least not on my system), but that's good enough to pass the most basic GB18030 test. Just like you correctly observe, "zh_CN.GB18030 as system locale" is not legally required, and thus no need to change the Debian installer or the locales package for that, so I wouldn't worry about that for Debian 12.0. (If the winds do change, we could hypothetically sneak in the change in, say, Debian 12.1. And the myriad of Debian derivatives in China can easily make that change for basic conformance too. Cheers, Anthony
Bug#1026231: debian-policy: document droppage of support for legacy locales
On Fri, Jan 20, 2023 at 7:27 AM Wouter Verhelst wrote: > > On Thu, Jan 19, 2023 at 11:47:42AM +, Simon McVittie wrote: > > Preferring to use Unicode does seem to be the direction that all of > > computing is going in, as a simplifying assumption - for example W3C > > advice for HTML is "You should always use the UTF-8 character encoding"[1] > > - and as we know, things that aren't tested usually don't work. So I > > think the level of functionality for non-UTF-8 locales and encodings in > > the software we package is going to decline over time, whether Debian > > wants it to or not. > > If the world's most populous country uses something that is not UTF-8, I > think it's safe to say it's being tested, if only by people who will > file bugs when things go awry. > > If the PRC government *requires* a non-UTF-8 encoding for things sold to > them, we would be doing our users who want to sell a product containing > Debian to the PRC government a disservice by dropping support for it > altogether. > > We don't have to ensure it works perfectly out of the box; just that > support is achievable with a reasonable amount of work. Thank you Wouter! That is exactly my thought, although after my initial message, I have been told that "zh_CN.GB18030 as system locale" may not be a strict requirement, and thus an explicit UI for selecting zh_CN.GB18030 as system locale may not be necessary. A fellow Chinese DD suggested that some documentation on how to edit /etc/locale.gen to enable zh_CN.GB18030 or other non-UTF-8 encodings would likely be sufficient. That said, if the testing authorities do want zh_CN.GB18030 to be easily selectable), I think we can always sneak "zh_CN.GB18030" into the locales configuration interface in a point release. Cheers, Anthony
Bug#1026231: debian-policy: document droppage of support for legacy locales
On Fri, Jan 20, 2023 at 7:42 AM Bill Allombert wrote: > > On Thu, Jan 19, 2023 at 11:47:42AM +, Simon McVittie wrote: > > On Wed, 18 Jan 2023 at 16:30:46 -0700, Anthony Fok wrote: > > > In their mind, GB 18030 encompasses a lot more than just > > > a character encoding mapping table. It is the full support package > > > (including fonts, display, printing, input methods, etc.) for Han > > > Chinese and all other minority languages used in China. > > > > Preferring to use Unicode does seem to be the direction that all of > > computing is going in, as a simplifying assumption - for example W3C > > advice for HTML is "You should always use the UTF-8 character encoding"[1] > > - and as we know, things that aren't tested usually don't work. So I > > think the level of functionality for non-UTF-8 locales and encodings in > > the software we package is going to decline over time, whether Debian > > wants it to or not. Re-reading Simon's comment again: Yes, UTF-8 is the ideal, but supposedly some older Chinese websites are still using "GBK" as encoding, probably something like: which has less than 30,000 characters and thus a very limited subset of Unicode. And, presumably not everyone has the know how to convert to UTF-8, the Chinese government wants those unable to at least change that meta tag to: where GB18030, being a Unicode Transformation Format, albeit a somewhat awkward one, would be able to display any characters in Unicode. > It is true for everything. Users know how to pick the software that works for > their > environment. It is not relevant that software they do not use do not support > their > environment. > > Telling users to switch to UTF-8 because such and such software they never > used > and were never going to use do not support GB18030 does not make sense. I have the feeling that many tech-savvy Chinese have already switched to UTF-8, but then perhaps in some circles there are lots of legacy GB2312/GBK documents or systems that made GB18030 a necessity, as an intermediate step to Unicode. (Not so in Taiwan and Hong Kong, they jump straight to UTF-8 from Big5 or Big5-HKSCS. For better or for worse.) > It is like saying the Linux console is deprecated because there are Debian > packages that requires X or Wayland. > > Cheers, > -- > Bill. > > Imagine a large red swirl here. Thanks for the wonderful discussion, Bill! Cheers, Anthony
Bug#1026231: debian-policy: document droppage of support for legacy locales
On Thu, Jan 19, 2023 at 4:47 AM Simon McVittie wrote: > > On Wed, 18 Jan 2023 at 16:30:46 -0700, Anthony Fok wrote: > > In their mind, GB 18030 encompasses a lot more than just > > a character encoding mapping table. It is the full support package > > (including fonts, display, printing, input methods, etc.) for Han > > Chinese and all other minority languages used in China. > > If I'm reading correctly, the character encoding part of GB 18030-2022 is > a subset of a sufficiently new version of Unicode, in the same way that > (say) ISO-8859-15 is a subset of Unicode: for every character representable > in GB 18030-2022, you can point at an equivalent Unicode character and say > "this is the GB 18030-2022 encoding of U+4E00" or similar? Is that true? If using ISO-8859-15 "legacy encoding" as comparison, in China that would be the 1980 "GB2312" (GB 2312-80) standard and the 1993 "GBK" extension. The character repertoires that these legacy encodings/charsets contain are far fewer than what Unicode or ISO/IEC 10646 encompasses, and in that sense, they are "subsets of Unicode". GB18030, on the other hand, is actually a full UTF or Unicode Transformation Format (i.e. an encoding of *all* Unicode code points), as in GB18030 maps to all codepoints of Unicode while maintaining backward compatibility with existing GB2312 and GBK documents, just like how UTF-8 maps to all codepoints of Unicode while maintaining backward compatibility with ASCII. GB18030 encodes characters into 1-byte, 2-byte or 4-byte sequences. 1-byte essentially ASCII; 2-byte: essentially GBK; the 4-byte sequences give a total of 1,587,600 (126×10×126×10) codepoints which easily and sufficiently cover Unicode's 1,112,064 (17×65536 − 2048 surrogates) assigned, reserved, and noncharacter code points. (source: Wikipedia) Since GB18030 can be used to represent the entirety of all Unicode code points, I would not call GB18030 a "subset" of Unicode. And some people like to think of GB18030 as "UTF-GBK", e.g. http://archives.miloush.net/michkap/archive/2013/03/28/10405914.html > If that's the case, then supporting text files written in GB 18030 > does not *necessarily* require the internal representation or the > system locale to be GB 18030, the same way I can still work with legacy > en_GB.ISO-8859-15 files on my en_GB.UTF-8 system: it could equally well > be done by using iconv() or equivalent to transcode to UTF-8, UTF-16 or > UCS-4 on input, doing all text editing operations on that Unicode, and > then transcoding back into GB 18030 on output. Most language frameworks > already do this as a matter of API: Qt, Java and Windows tend to work > with UTF-16 internally, while GLib/GTK uses UTF-8 internally. Very true. While GB18030 is another encoding form for Unicode (and not a subset), indeed we don't need to use GB18030 as the "internal representation or the system locale", you have put it very nicely. GB18030 is also somewhat inefficient as a UTF as the required mapping table and 4-byte conversion algorithm take up far more space and are quite a bit slower than something as elegant as UTF-8. > iconv() seems very unlikely to drop support for GB 18030, ISO-8859-15 and > other non-Unicode encodings altogether. What this bug report is about is > dropping support for locales whose associated encoding is non-Unicode, > such as en_GB.ISO-8859-15 and zh_CN.GB18030, so that the data stream > between a CLI program and the terminal emulator will be assumed to be UTF-8 > instead of ISO-8859-15 or GB18030. Indeed, and thankfully, Google Chrome, Mozilla Firefox, LibreOffice supposedly still support the reading (and writing) of GB18030 documents through iconv() or ICU or Qt's encoding conversions. > The main thing I can see that would be a problem for GB 18030 users > if the zh_CN.GB18030 locale was dropped is that various programs might > assume that the locale encoding is the right one to assume when loading > existing files and unable to guess the encoding, or the right one to > write into new files by default - and so users who have moved from > zh_CN.GB18030 to zh_CN.UTF-8 might find themselves unintentionally > producing new UTF-8 files. Yes. These are some of the pains as we transition from legacy GB2312/GBK encodings towards Unicode, and GB18030 (being a UTF) is designed as a stepping stone. But yes, moving to UTF-8 is indeed a good thing, even in China, as China is not an isolated island. China people do value interoperability with the world too. > Preferring to use Unicode does seem to be the direction that all of > computing is going in, as a simplifying assumption - for example W3C > advice for HTML is "You should always use the UTF-8 character encoding"[1] > - and as we know, things that aren't tested usually don't wo
Bug#1026231: debian-policy: document droppage of support for legacy locales
On Wed, Jan 18, 2023 at 6:30 PM Russ Allbery wrote: > > Anthony Fok writes: > > > I'm not asking you to spend any time working on GB18030; that would be > > the job of Debian Chinese i18n/L10n team as well as the wider community > > (glibc, libiconv, Qt, etc.) All I am asking you is to maintain the > > status quo, and don't discount anything other than UTF-8 as legacy. > > This topic comes up a lot, and I'd love to put something in either Policy > or the Developer's Reference proactively to at least explain what we know > about what our users need and to point people at the right questions to > ask if it's been another decade and they want to standardize on UTF-8 > again. Do you have an idea of something suitable we should say? Hey Russ, thank you so much for your message! Adam, I would like to apologize; while I still value that Debian maintains its existing support for zh_CN.GB18030 locale, I did speak a bit too soon. I'll elaborate. > I do think we probably should say more *somewhere* about making UTF-8 the > default choice in most situations if you otherwise have no reason to > choose anything specific. I totally agree. Besides the Debian Policy A fellow DD on #debian-zh IRC (linked with Telegram) channel suggests that UTF-8 being the default should be mentioned in the Release Notes and probably with pointers to fuller documentation, with instructions on how to manually add locales with legacy and other non-UTF-8 encodings edit /etc/locale.gen and /etc/default/locale, and run locale-gen. > For example, as you point out, files written in > Chinese for Chinese people may or may not want to use UTF-8, but at this > point I do think anything written in, say, French or German probably > should just use UTF-8. Totally agreed. And I should clarify: Actually, I would say, for the majority of end users in Mainland China, zh_CN.UTF-8 would still be the best default, though likely some government and financial institutions may require the use of zh_CN.GB18030 probably for certain terminal applications. I don't know the percentage though. I asked around #debian-zh last night for more feedback, and most existing users/developers definitely prefer UTF-8 and are using zh_CN.UTF-8. Some joked that those who choose zh_CN.GB18030 are the ones who like to create difficulties for themselves. And while support for zh_CN.GB18030 as a "system locale" was apparently a requirement for conformance testing for GB 18030-2000 some twenty years ago — I went through that period personally when there was a mad dash by all Linux vendors to get that as well as fonts and input methods working properly — fellow Chinese DDs agree that could be a requirement 20 years ago, but no longer today, and suggest that all China homegrown nowadays use LANG=zh_CN.UTF-8 by default, and apparently still pass the GB 18030(-2005?) conformance tests. They suggest that probably having the ability to read and write GB18030-encoded documents, and being able to convert between UTF-8 and GB18030 etc. should be sufficient. I was initially unconvinced, but then after testing in virtual machine various ISO images from latest releases of China homegrown Linux distributions, e.g. Deepin Linux, openKylin, and even Red Flag Desktop Linux, and they all use zh_CN.UTF-8 as the default system locale! (Red Flag does have zh_CN.gb18030 locale precompiled though, but then it seems to have all available locales precompiled according to "locale -a". Incidentally, Red Flag Desktop Linux is now based on Debian too! They used to co-develop the RHEL-based Asianux on which they built their distro. What a pleasant surprise! > Also, file names in the file system shipped in > Debian packages probably should use UTF-8 since there's no way to declare > the character set and there are some solid reasons for picking one and > sticking with it. (Obviously, users can create files with any character > set they want.) Great point! Totally agreed > > Debian already supports GB 18030-2000 (or GB 18030-2005) rather well. > > How do I configure a locale that uses this as the default character set? > I'd like to be able to test this configuration (at least for my own > packages), but since recent changes to locales it doesn't appear to be an > option in debconf and I was confused trying to figure out how I should > make it work. Good question! I somehow missed that removal of "legacy" encodings from the locales dpkg configure menu... so that's why Adam was saying official support for legacy locales have indeed been dropped. (Thanks Adam! You're just speaking the facts.) Anyhow, to test how Debian and various desktop environments run under zh_CN.GB18030 as system locale, here are the steps: 1. Create the /usr/local/share/i18n/SUPPORTED file with the line zh_CN.GB18030 GB18030 (I actually started by prepending t
Bug#1022001: libwebp: Please package new upstream release 1.2.4
On Tue, Oct 18, 2022 at 1:15 PM Boyuan Yang wrote: > > Source: libwebp > Version: 1.2.2-2 > Severity: normal > Tags: sid > X-Debbugs-CC: j...@debian.org > > Dear Debian libwebp package maintainer, > > A new upstream release for libwebp is available at > https://storage.googleapis.com/downloads.webmproject.org/releases/webp/index.html > . Please consider packaging it. > > Also, the package libavif I maintain has libsharpyuv as a new build- > dependency, which is provided by src:libwebp in the new release. Please also > consider providing the libsharpyuv library. Thanks! > > Best, > Boyuan Yang Hi Jeff, First of all, thank you so much for maintaining libwebp. Like Boyuan, I do have a need for an updated libwebp package: libwebp 1.2.4 is needed by golang-github-bep-gowebp which is in turn used by hugo >= 0.106.0, and since I'd very much like to get the latest hugo 0.110.0 into Debian 12 (bookworm) before the impending freeze, may I go ahead and package libwebp 1.2.4 and do a NMU? Many thanks for your understanding! Cheers, Anthony
Bug#1026231: debian-policy: document droppage of support for legacy locales
Hello, On Mon, Dec 19, 2022 at 2:48 PM Bill Allombert wrote: > Which raise the question: does the corresponding user group moved to UTF-8 ? > Judging from <https://en.wikipedia.org/wiki/Chinese_character_encoding>, > neither Chinese nor Japanese users have overwhelmingly moved to UTF-8, > so it would be problematic to stop supporting BIG5, GB18030 and EUC-JP. Bill, thank you, thank you, thank you! You speak the voice of reason! Adam, we living in the West may think of BIG5, GB18030 and EUC-JP as legacy/obsolete encodings, but in Mainland China, GB18030 is anything but legacy. It is a mandatory national standard that has recently been brought up to date in GB 18030-2022, synchronizing with ISO/IEC 10646:2017 (equivalent to Unicode version 11.0). "GB 18030 is a national standard with stringent conformance requirements that regulate eligibility for products or services to be sold in China." I personally went through this trying to get the now defunct ThizLinux distro GB 18030-2000 conformant 20 years ago. GB 18030-2022 will become mandatory on 2023-08-01. Why the urgency? To add support 17000+ rarer CJK Han characters found in people's and place names, as well as improving support for minor ethnic languages in China. And the GB18030 standard committee is really serious about promoting GB18030 because they are eager to resolve some real issues of "missing characters" that are negatively affecting the people living in China. To my pleasant surprise, they are putting out a public lecture webinar series that explains the why and the how of implementing GB 18030-2022, with the 3rd video published on 2022-12-30. In their mind, GB 18030 encompasses a lot more than just a character encoding mapping table. It is the full support package (including fonts, display, printing, input methods, etc.) for Han Chinese and all other minority languages used in China. See e.g. the following excellent articles for more information: * https://ken-lunde.medium.com/the-gb-18030-2022-standard-3d0ebaeb4132 * https://www.unicode.org/L2/L2022/22274-disruptive-changes.pdf Even though Debian is not proprietary/commercial software, the GB 18030 authority highly recommends that free/libre and open-source software _do_ implement GB 18030-2022. That's especially true considering the fact that vendors in China may be offering Debian as a solution for clients, but they would be prevented from doing so if Debian Policy spells out "We support UTF-8 and UTF-8 only. Think of all the ARM and RISC-V single-board computers made in China where Debian is the default OS image; Debian or derivatives (Ubuntu, Ubuntu Kylin, etc.) that are pre-installed on PCs sold in China, etc. As a matter of fact, I have been recently approached recently to update the IANA charset technical summary for "GB18030" (i.e. the original GB 18030-2000) in https://www.iana.org/assignments/charset-reg/GB18030 with the latest updates for GB 18030-2022. (Haha, I am starting to fret about it because I am no expert in GB18030, but many thanks to e.g. Dr. Ken Lunde, the expert in CJKV information processing, who has kindly allowed me to borrow any of his articles in updating the IANA charset documentation for GB18030. I'm not asking you to spend any time working on GB18030; that would be the job of Debian Chinese i18n/L10n team as well as the wider community (glibc, libiconv, Qt, etc.) All I am asking you is to maintain the status quo, and don't discount anything other than UTF-8 as legacy. Debian already supports GB 18030-2000 (or GB 18030-2005) rather well. Don't let that existing support die! If anything, we'd need to improve GB18030 support to conform with GB 18030-2022, though thankfully much of that work would likely come from upstream projects or from Debian derivatives or other distros that are actually selling their products in China. Many thanks for your understanding! Kind regards, Anthony Fok
Bug#1026200: Please package LilyPond 2.24.0 if possible
On Sat, Jan 14, 2023 at 2:36 PM Jonas Hahnfeld wrote: > > On Wed, 2022-12-28 at 22:16 +0100, Jonas Hahnfeld wrote: > > On Fri, 16 Dec 2022 15:27:32 +1100 John Zaitseff > > wrote: > > > Package: lilypond > > > Severity: wishlist > > > > > > I know it's a lot to ask for :-), but now that LilyPond 2.24.0 has > > > been released, it would be good to have it in Debian. Let me know > > > if I can help bring this about! > > > > Yes, please actually, aligning our release of LilyPond 2.24.0 with > > Debian's freeze plans was very intentional: > > https://lists.gnu.org/archive/html/lilypond-devel/2022-05/msg00099.html > > > > That said, I just realized that guile-2.2-libs has been *removed* as > > part of #1023560 while it is the preferred version of Guile for this > > release of LilyPond. What are the chances of getting this back into the > > repos? > > Ping, also CC'ing Rob Browning for Guile. Hello Jonas (and Rob) and all, Thank you so much for the bug report and reminders, which are much needed and appreciated! I had been away from my Debian duties and missed the initial report, but finally saw he January 12th message from Jean Abou Samra who added: > The Guile version makes a difference to the Scheme code you can write, > so compatibility issues are not hypothetical. Furthermore, I think > Guile 2.2 would still have value independently from LilyPond: > right now, compiling Guile 3.0 for Windows requires lots of patches > to be found in work-in-progress experimental branches, so > if you want to write portable software, you more or less need > to use Guile 2.2. Thank you so much for Cc'ing Rob regarding Guile-2.2. Rob, as you can see, there is a real need for Guile 2.2 for LilyPond 2.24.0 (December 2022), this coming from LilyPond's Core Developer Jonas Hahnfeld and "Factotum" and Jean Abou Samra. If it is OK with you, Rob, I would be more than happy to adopt guile-2.2 and maintain it for the entire lifetime of Debian 12 (bookworm), and hopefully by Debian 13 (trixie), LilyPond will be ready for guile-3.0. :-)\ Many thanks for your understanding! Warm regards, Anthony
Bug#1028414: frescobaldi 3.2 fails to launch with Python 3.11
Package: frescobaldi Version: 3.2+ds1-1 Severity: important Tags: upstream Forwarded: https://github.com/frescobaldi/frescobaldi/issues/1453 X-Debbugs-Cc: f...@debian.org Launching frescobaldi 3.2+ds1-1 on Debian bookworm/sid with Python 3.11 fails with the following error: Traceback (most recent call last): File "/home/foka/git/frescobaldi/frescobaldi_app/view.py", line 107, in event if ev.type() == QEvent.KeyPress: ^^^ TypeError: a member of enum 'StandardKey' is expected not 'QEvent' Aborted A temporary workaround is to run frescobaldi with an older Python version, e.g.: $ python3.10 /usr/bin/frescobaldi The issue was reported to upstream by Fedora users/developers back in October 2022, and there is a pull request that may resolve the problem; see https://github.com/frescobaldi/frescobaldi/issues/1453 -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages frescobaldi depends on: ii python33.11.1-1 ii python3-ly 0.9.7-1 ii python3-poppler-qt521.3.0-2 ii python3-pygame 2.1.2+dfsg-5 ii python3-pyqt5 5.15.7+dfsg-3+b1 ii python3-pyqt5.qtsvg5.15.7+dfsg-3+b1 ii python3-pyqt5.qtwebengine 5.15.6-1 ii python3-pyqt5.qtwebkit 5.15.7+dfsg-3+b1 ii python3-qpageview 0.6.2-4 ii tango-icon-theme 0.8.90-11 Versions of packages frescobaldi recommends: ii fluidsynth 2.3.1-1 ii lilypond2.22.2-1 Versions of packages frescobaldi suggests: ii hyphen-en-us [hyphen-hyphenation-patterns] 2.8.8-7 ii lilypond-doc2.22.2-1 -- no debconf information
Bug#1020585: ITP: golang-github-marekm4-color-extractor -- simple image color extractor written in Go
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-marekm4-color-extractor Version : 1.2.0-1 Upstream Author : Marek Michalik * URL : https://github.com/marekm4/color-extractor * License : Expat Programming Lang: Go Description : simple image color extractor written in Go Simple image color extractor written in Go with no external dependencies. . Demo: https://color-extractor-demo.herokuapp.com/ . Blog post: https://medium.com/@marek.michalik/c-vs-rust-vs-go-performance-analysis-945ab749056c Reason for packaging: Needed by hugo (>= 0.104.0)
Bug#1016626: RM: golang-1.17 -- ROM; superseded by golang-1.18
On Wed, Aug 3, 2022 at 8:48 PM Shengjing Zhu wrote: > > Package: ftp.debian.org > Severity: normal > X-Debbugs-Cc: z...@debian.org, team+go-compi...@tracker.debian.org > > Please remove golang-1.17 from unstable, it has been superseded by > golang-1.18. > Thanks Hello Debian FTP Masters, Please kindly wait at least until golang-1.17 (1.17.13-3) migrates into testing before removing golang-1.17, especially 1.17.13 fixes some security vulnerabilities that it would be nice for end users on Debian testing who already have golang-1.17 installed to be able to to upgrade this final golang-1.17 release. How about waiting till August 31 or after? :-) Many thanks! Anthony
Bug#916202: ITP: golang-github-mmarkdown-mmark -- Mmark: a powerful markdown processor in Go geared towards the IETF
Control: tags -1 + pending On Sun, Aug 7, 2022 at 12:03 PM Scott Kitterman wrote: > > On Sun, 10 Nov 2019 23:22:21 -0700 Anthony Fok wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Anthony Fok > > X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org > > > > * Package name: golang-github-mmarkdown-mmark > > Version : 2.2.0-1 > > Upstream Author : Miek Gieben > > * URL : https://github.com/mmarkdown/mmark > > * License : BSD-2-Clause > > Programming Lang: Go > > Description : Mmark: a powerful markdown processor in Go geared > towards the IETF > > > > Rationale: There has been interests to see Mmark v2.0.0 packaged. > > It would be really great to see this in Debian. The defaults have changed > between the older version last in Debian and the current package, so I'm > running into problems using the old Debian version with Makefiles people are > writing based on the current defaults. > > Thanks for considering, Hi Scott, Thank you for the reminder! I can't believe it has been almost three years since I planned to package Mmark v2, but I totally forgot about it, leaving Debian without the mmark binary at all in Debian 11 (bullseye) when I removed it from golang-github-miekg-mmark 1.3.6-2 on 2019-11-10. (Sorry! Should have started packaging mmark v2 right then.) Anyhow, the new mmark 2.2.5+dfsg1-1 package and its dependency golang-github-gomarkdown-markdown are now sitting in the NEW queue and should be available soon. Cheers, Anthony
Bug#1016994: ITP: golang-github-gomarkdown-markdown -- Markdown parser and HTML renderer for Go
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-gomarkdown-markdown Version : 0.0~git20220731.dcdaee8-1 Upstream Authors: Russ Ross, Krzysztof Kowalczyk, Authors * URL : https://github.com/gomarkdown/markdown * License : BSD-2-clause Programming Lang: Go Description : Markdown parser and HTML renderer for Go Package github.com/gomarkdown/markdown is a Go library for parsing Markdown text and rendering as HTML. . It's very fast and supports common extensions. . markdown is a fork of v2 of https://github.com/russross/blackfriday that is: . * actively maintained (sadly in Feb 2018 blackfriday was inactive for 5 months with many bugs and pull requests accumulated) * refactored API (split into ast/parser/html sub-packages) . Blackfriday itself was based on C implementation sundown (https://github.com/vmg/sundown) which in turn was based on libsoldout (http://fossil.instinctive.eu/libsoldout/home). Reason for packaging: Required by golang-github-mmarkdown-mmark (See ITP at #916202)
Bug#1016993: ITP: golang-github-thlib-go-timezone-local -- Get the full name of the local timezone (Go library)
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-thlib-go-timezone-local Version : 0.0~git20210907.ef149e4-1 Upstream Author : Timo Huovinen * URL : https://github.com/thlib/go-timezone-local * License : Unlicense Programming Lang: Go Description : Get the full name of the local timezone (Go library) This Go library package provides the full name of the local timezone from OS setting. Works on Windows, Linux and macOS. Reason for packaging: Required by latest golang-github-cli-go-gh as part of gh (GitHub CLI).
Bug#1013519: hugo: FTBFS: unsatisfiable build-dependency: golang-gopkg-yaml.v2-dev (>= 3.0.1) but 2.4.0-3 is to be installed
Control: reassign -1 golang-github-getkin-kin-openapi Control: found -1 golang-github-getkin-kin-openapi/0.97.0-1 On Fri, Jun 24, 2022 at 4:12 AM Lucas Nussbaum wrote: > Source: hugo > Version: 0.100.2-1 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20220624 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > +--+ > > | Install package build dependencies > >| > > +--+ > > > > > > Setup apt archive > > - > > > > Merged Build-Depends: asciidoctor, debhelper (>= 13.4), debhelper-compat (= > > 13), dh-sequence-bash-completion, dh-sequence-golang, golang-any (>= > > 2:1.18~), golang-github-alecthomas-chroma-dev (>= 0.10.0), > > golang-github-armon-go-radix-dev, golang-github-aws-aws-sdk-go-dev (>= > > 1.43.5), golang-github-bep-clock-dev (>= 0.3.0), > > golang-github-bep-debounce-dev (>= 1.2.0+really1.2.0), > > golang-github-bep-gitmap-dev (>= 1.1.2), golang-github-bep-goat-dev (>= > > 0.5.0), golang-github-bep-godartsass-dev (>= 0.14.0), > > golang-github-bep-golibsass-dev (>= 1.1.0), golang-github-bep-gowebp-dev > > (>= 0.1.0), golang-github-bep-overlayfs-dev (>= 0.6.0), > > golang-github-bep-tmc-dev (>= 0.5.1), golang-github-clbanning-mxj-dev (>= > > 2.5.5), golang-github-burntsushi-locker-dev, golang-github-cli-safeexec-dev > > (>= 1.0.0), golang-github-disintegration-gift-dev (>= 1.2.1), > > golang-github-dustin-go-humanize-dev (>= 1.0.0), > > golang-github-evanw-esbuild-dev (>= 0.14.42), > > golang-github-fortytw2-leaktest-dev, golang-github-frankban-quicktest-dev > > (>= 1.14.3), golang-github-fsnotify-fsnotify-dev (>= 1.5.4), > > golang-github-getkin-kin-openapi-dev (>= 0.94.0), > > golang-github-ghodss-yaml-dev, golang-github-go-playground-locales-dev (>= > > 0.14.0), golang-github-gobuffalo-flect-dev (>= 0.2.5), > > golang-github-gobwas-glob-dev, golang-github-google-go-cmp-dev (>= 0.5.8), > > golang-github-gorilla-websocket-dev (>= 1.5.0), > > golang-github-hairyhenderson-go-codeowners-dev (>= > > 0.2.2+git20201026.cdc7c07), golang-github-jdkato-prose-dev (>= 1.2.1), > > golang-github-kylelemons-godebug-dev (>= 1.1.0), > > golang-github-kyokomi-emoji-dev (>= 2.2.9), > > golang-github-mattn-go-isatty-dev (>= 0.0.14), > > golang-github-mitchellh-hashstructure-dev (>= 1.1.0), > > golang-github-mitchellh-mapstructure-dev (>= 1.5.0), > > golang-github-muesli-smartcrop-dev (>= 0.3.0), > > golang-github-niklasfasching-go-org-dev (>= 1.6.2), > > golang-github-olekukonko-tablewriter-dev (>= 0.0.5), > > golang-github-pelletier-go-toml.v2-dev (>= 2.0.1), > > golang-github-puerkitobio-purell-dev (>= 1.1.1), > > golang-github-rogpeppe-go-internal-dev (>= 1.8.1), > > golang-github-rwcarlsen-goexif-dev (>= 0.0~git20190401.9e8deec), > > golang-github-sanity-io-litter-dev (>= 1.5.5), > > golang-github-spf13-afero-dev (>= 1.8.2), golang-github-spf13-cast-dev (>= > > 1.5.0), golang-github-spf13-cobra-dev (>= 1.4.0), > > golang-github-spf13-fsync-dev (>= 0.9.0), > > golang-github-spf13-jwalterweatherman-dev (>= 1.1.0+really1.1.0), > > golang-github-spf13-pflag-dev (>= 1.0.5), golang-github-tdewolff-minify-dev > > (>= 2.11.5), golang-github-tdewolff-parse-dev (>= 2.5.31), > > golang-github-yuin-goldmark-dev (>= 1.4.12), golang-go.uber-atomic-dev (>= > > 1.9.0), golang-gocloud-dev (>= 0.20.0-3~), golang-golang-x-image-dev (>= > > 0.0~git20211028.6944b10), golang-golang-x-net-dev (>= > > 1:0.0+git20220425.2871e0c), golang-golang-x-sync-dev (>= > > 0.0~git20210220.036812b), golang-golang-x-text-dev (>= 0.3.7), > > golang-google-api-dev (>= 0.61.0), golang-gopkg-yaml.v2-dev (>= 2.4.0), > > libsass-dev (>= 3.6.5), libwebp-dev, python3-docutils, build-essential, > > fakeroot > > Filtered Build-Depends: asciidoctor, debhelper (>= 13.4), debhelper-compat > > (= 13), dh-sequence-bash-completion, dh-sequence-golang, golang-any (>= > > 2:1.18~), golang-github-alecthomas-chroma-dev (>= 0.10.0), > > golang-github-armon-go-radix-dev, golang-github-aws-aws-sdk-go-dev (>= > > 1.43.5), golang-github-bep-clock-dev (>= 0.3.0), > > golang-github-bep-debounce-dev (>= 1.2.0+really1.2.0), > > golang-github-bep-gitmap-dev (>= 1.1.2), golang-github-bep-goat-dev (>= > > 0.5.0), golang-github-bep-godartsass-dev (>= 0.14.0), > > golang-github-bep-golibsass-dev (>= 1.1.0), golang-github-bep-gowebp-dev > > (>= 0.1.0), golang-github-bep-overlayfs-dev (>= 0.6.0), > > golang-github-bep-tmc-dev (>= 0.5.1), golang-github-clbanning-mxj-dev (>= > > 2.5.5), golang-github-burntsushi-locker-dev, golang-github-cli-safeexec-dev > > (>= 1.0.0), golang-github-disintegration-gift-dev (>= 1.2.1), > >
Bug#994930: guile-2.2: FTBFS due to web-server.test error
Control: severity -1 important
On Thu, 23 Sep 2021 16:19:54 +0530 Vignesh Raman
wrote:
> Package: guile-2.2
> Version: 2.2.7+1-6
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> X-Debbugs-Cc: vignesh.ra...@collabora.com
>
> Dear Maintainer,
>
> When building the guile-2.2_2.2.7+1-6, it failed to build from the source for
> arm64.
>
> The below error was seen,
>
> Running web-server.test
> ERROR: web-server.test: GET / - arguments: ((system-error "connect" "~A"
> ("Connection refused") (111)))
> Running web-uri.test
> UNRESOLVED: web-uri.test: build-uri: http://ill\xe9gal.com
> UNRESOLVED: web-uri.test: string->uri: http://www.example.com (sv_SE)
>
> Totals for this test run:
> passes: 41898
> failures: 0
> unexpected passes: 0
> expected failures: 10
> unresolved test cases: 578
> untested test cases:1
> unsupported test cases: 1
> errors: 1
>
> FAIL: check-guile
> ==
> 1 of 1 test failed
>
> The failure is not always reproducible and looks to be an intermittent issue.
> Similar error is reported in https://bugs.gentoo.org/712362
>
> Please could you check this issue. Thanks.
>
> Regards,
> Vignesh
Thank you for the report, Vignesh.
As this issue is rather intermittent, and it has happened only once on
the Debian arm64 buildd for 2.2.3+1-2 back in 2018 (see
https://buildd.debian.org/status/logs.php?pkg=guile-2.2=arm64 ;
all other intermittent build errors were due to test-out-of-memory),
and since guile-2.2 has been building fine on all architectures, I am
hereby downgrading the severity from "serious" to "important".
Cheers,
Anthony Fok
Bug#1013173: ITP: golang-github-invopop-yaml -- better way to marshal and unmarshal YAML in Golang
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-invopop-yaml Version : 0.2.0-1 Upstream Authors: Sam Ghods, The Go Authors, Sam Lown * URL : https://github.com/invopop/yaml * License : Expat, BSD-3-Clause Programming Lang: Go Description : better way to marshal and unmarshal YAML in Golang This package is a wrapper around go-yaml (gopkg.in/yaml.v3) designed to enable a better way of handling YAML when marshaling to and from structs. . This is a fork and split of the original github.com/ghodss/yaml repository which no longer appears to be maintained. . In short, this library first converts YAML to JSON using go-yaml and then uses json.Marshal and json.Unmarshal to convert to or from the struct. This means that it effectively reuses the JSON struct tags as well as the custom JSON methods MarshalJSON and UnmarshalJSON unlike go-yaml. Reason for packaging: Dependency of golang-github-getkin-kin-openapi 0.97.0 and up.
Bug#1012796: ITP: golang-github-cli-go-gh -- Go module for interacting with gh and the GitHub API from the command line
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-cli-go-gh Version : 0.0.3-1 Upstream Author : GitHub Inc. * URL : https://github.com/cli/go-gh * License : Expat Programming Lang: Go Description : Go module for interacting with gh and the GitHub API from the command line go-gh is a Go module for CLI Go applications and gh extensions that want a convenient way to interact with gh, and the GitHub API using gh environment configuration. . go-gh supports multiple ways of getting access to gh functionality: . * Helpers that automatically read a gh config to authenticate themselves * gh.Exec shells out to a gh install on your machine . If you'd like to use go-gh on systems without gh installed and configured, you can provide custom authentication details to the go-gh API helpers. Reason for packaging: Needed by gh v2.12.1 and up
Bug#1011838: xonsh: FTBFS: ModuleNotFoundError: No module named 'attr'
Control: reassign -1 python3-myst-parser Control: affects -1 + xonsh Control: found -1 python3-myst-parser/0.16.1-1 Control: found -1 python3-myst-parser/0.16.1-2 Control: found -1 python3-myst-parser/0.16.1-3 Control: found -1 python3-myst-parser/0.16.1-4 Control: fixed -1 python3-myst-parser/0.17.2-1 On Thu, May 26, 2022 at 1:26 PM Lucas Nussbaum wrote: > > Source: xonsh > Version: 0.12.4+dfsg-1 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20220525 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > make[2]: Entering directory '/<>/docs' > > sphinx-build -b html -d _build/doctrees . _build/html > > Running Sphinx v4.5.0 > > > > Exception occurred: > > File "/usr/lib/python3/dist-packages/myst_parser/main.py", line 3, in > > > > import attr > > ModuleNotFoundError: No module named 'attr' > > The full traceback has been saved in /tmp/sphinx-err-f46ojpq1.log, if you > > want to report the issue to the developers. > > Please also report this if it was a user error, so that a better error > > message can be provided next time. > > A bug report can be filed in the tracker at > > <https://github.com/sphinx-doc/sphinx/issues>. Thanks! > > make[2]: *** [Makefile:39: html] Error 2 > > > The full build log is available from: > http://qa-logs.debian.net/2022/05/25/xonsh_0.12.4+dfsg-1_unstable.log > > All bugs filed during this archive rebuild are listed at: > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20220525;users=lu...@debian.org > or: > https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20220525=lu...@debian.org=1=1=1=1#results > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > If you reassign this bug to another package, please marking it as > 'affects'-ing > this package. See https://www.debian.org/Bugs/server-control#affects > > If you fail to reproduce this, please provide a build log and diff it with > mine > so that we can identify if something relevant changed in the meantime. As it turns out, this is not a bug in xonsh, but rather in python3-myst-parser 0.16.1 where the line "from attr import Attribute" was added, but without dependency on the python3-attr. xonsh became a "victim" of that missing dependency. The good news is that the xonsh FTBFS problem is fixed with the upload of python3-myst-parser 0.17.2-1 where upstream did this: - ♻️ REFACTOR: Replace `attrs` by `dataclasses` for configuration (#557) The 'attr' module is no longer needed, hence no more FTBFS for xonsh! Special thanks to Emmanuel Arias and Bastian Germann for the upload of myst-parser 0.17.2-1 which resolves this bug. I am hereby reassigning this bug to python3-myst-parser, and will close the bug shortly after. Cheers, Anthony Fok
Bug#1010408: ftbfs: Error: Failed to find "global.fs = fs;" in Go JS shim code
Hi Jérémy,
Thank you for your report!
On Sat, Apr 30, 2022 at 2:39 PM Jérémy Lal wrote:
> Source: golang-github-evanw-esbuild
> Version: 0.14.25-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the
past)
>
> your package FTBFS, however a trivial upstream update fixes it (took me a
minute to rebuild it).
I'd like to provide a bit more context:
esbuild v0.14.25 started FTBFS when golang-1.18 became the default in
Debian on about 2022-03-22.
The actual FTBFS error looks something like this:
=
debian/rules execute_after_dh_auto_build-arch
make[1]: Entering directory '/<>'
ln -s _build/bin/esbuild .
# Generate npm/esbuild/*
node scripts/esbuild.js ./esbuild --neutral
# Generate npm/esbuild-wasm/*
GOPATH=/<>/_build GOCACHE=/<>/_build/go-build \
node scripts/esbuild.js ./esbuild --wasm
/<>/scripts/esbuild.js:110
if (wasm_exec_js.indexOf(toReplace) === -1) throw new Error(`Failed to
find ${JSON.stringify(toReplace)} in Go JS shim code`);
^
Error: Failed to find "global.fs = fs;" in Go JS shim code
at replace (/<>/scripts/esbuild.js:110:55)
at Object.exports.buildWasmLib
(/<>/scripts/esbuild.js:113:3)
at Object. (/<>/scripts/esbuild.js:366:52)
at Module._compile (node:internal/modules/cjs/loader:1105:14)
at Object.Module._extensions..js
(node:internal/modules/cjs/loader:1159:10)
at Module.load (node:internal/modules/cjs/loader:981:32)
at Function.Module._load (node:internal/modules/cjs/loader:822:12)
at Function.executeUserEntryPoint [as runMain]
(node:internal/modules/run_main:77:12)
at node:internal/main/run_main_module:17:47
make[1]: *** [debian/rules:25: execute_after_dh_auto_build-arch] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:17: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit
status 2
=
This was apparently fixed in the upstream commit
-
https://github.com/evanw/esbuild/commit/517f77fa11da2287b4f63680cee9544be1f88c76
which was released upstream as v0.14.28 on 2022-03-25.
Bug#1011545: [Debian Bug Tracking System] Bug#1011545 closed by Debian FTP Masters (reply to Anthony Fok ) (Bug#1011545: fixed in gh 2.4.0+dfsg1-3)
Control: reopen -1 Control: severity -1 important Hi Antoine! Thank you for your quick response! On Tue, May 31, 2022 at 9:58 AM Antoine Beaupré wrote: > > Hum. Now I'm a little confused: why did you do this? > > * Add diversion for /usr/bin/gh to allow concurrent install with gitsome > and remove Conflicts with gitsome. This is inspired by the conflict > resolution between the moreutils and parallel packages where both > contain /usr/bin/parallel. See discussions in #749355. This is an idea that has been brewing in my mind some weeks ever since I came to realize Debian has two "parallel" programs while working on <https://github.com/OpenDRR/earthquake-scenarios/pull/61>, and thought to myself, if moreutils and (GNU) parallel can do it, why can't gitsome and (GitHub's) gh? But I was too busy with work, and also not sure how to break the file conflict deadlock in #1005858 (especially with the manual block to both packages), so I didn't act on it. Many thanks to you for getting us out of that embarrassing situation! So, as I was dealing with this new bug that you opened, my old idea came back to me again, I decided to give it a try, for better or for worse. The changelog is a reflection of the Git commits that I made in that order... > This seems like it's the opposite of what I was suggesting in the bug > report (#1011545). And you even refer to that bug report in the > changelog: > > * Limit "Conflicts: gitsome" to older (<< 0.8.0+ds-7.1) versions. > Thanks to Antoine Beaupre for the suggestion, and for resolving the > file conflict with gitsome (#1005858) so amicably! (Closes: #1011545) > > What actually happened, from what I can tell, is that you just removed > the Conflicts... I don't think that's the right resolution here: gitsome > has been fixed, in unstable, and gh doesn't need to go around with fancy > diversion stuff, because we're *precisely* not in a situation like > moreutils and parallel... Thank you for clarifying to me that it is a different situation than moreutils and parallel. >From my understanding of the gitsome, the "gitsome" command itself is mostly just a wrapper that calls xonsh, and gitsome's main functionalities are actually in the "/usr/bin/gh" Python executable, so perhaps removing /usr/bin/gh altogether in some sense cripples the gitsome package, and a rename to /usr/bin/gh.gitsome or something else would be more appropriate. That said, I now agree with you that renaming gitsome's /usr/bin/gh via dpkg-divert from GitHub CLI gh package is not the right way to go, particularly because the /usr/bin/gh meaning different things depending on which packages are installed (just gitsome or both gitsome and gh) can be very confusing.) > Could this change be reverted? Yes, most definitely! I will do it ASAP. After that, I will probably try to work on the gitsome package too and install its gh as /usr/bin/gh.gitsome and hopefully get its command-line completion to work with the name change, but that's unrelated to this particular bug report and to GitHub CLI gh. Let's keep this package clean and free of the fancy and confusing diversion stuff. :-) Thanks again for writing to me and put some common sense back into me! Cheers, Anthony Fok > -- > When I came back to the United States, I decided that if you could use > propaganda for war, you could certainly use it for peace. And > "propaganda" got to be a bad word because of the Germans using it, so > what I did was to try and find some other words so we found the words > "public relations". - Edward Bernays > > > > > > -- Forwarded message -- > From: Debian Bug Tracking System > To: Antoine Beaupre > Cc: > Bcc: > Date: Tue, 31 May 2022 15:51:05 + > Subject: Bug#1011545 closed by Debian FTP Masters > (reply to Anthony Fok ) > (Bug#1011545: fixed in gh 2.4.0+dfsg1-3) > This is an automatic notification regarding your Bug report > which was filed against the gh package: > > #1011545: please version the Conflicts: with gitsome > > It has been closed by Debian FTP Masters > (reply to Anthony Fok ). > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Debian FTP Masters > (reply to Anthony Fok ) by > replying to this email. > > > -- > 1011545: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011545 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > > > > ------ Forwarded message -- > From: Debian FTP Masters > To: 1011545-cl...@bugs.debian.org > Cc: > Bcc: > Date: Tue, 31 May 2022
Bug#1012123: ITP: golang-github-bep-clock -- Golang clock that allows you to set the start time (Go library)
Package: wnpp
Severity: wishlist
Owner: Anthony Fok
* Package name: golang-github-bep-clock
Version : 0.3.0-1
Upstream Author : Bjørn Erik Pedersen
* URL : https://github.com/bep/clock
* License : Expat
Programming Lang: Go
Description : Golang clock that allows you to set the start time (Go
library)
This package provides a *ticking clock* that allows you to set the start
time. It also provides a system clock, both implementing this interface:
.
// Clock provides a subset of methods in time.Time
type Clock interface {
Now() time.Time
Since(t time.Time) time.Duration
Until(t time.Time) time.Duration
.
// Offset returns the offset of this clock relative to the system clock
Offset() time.Duration
}
.
Note that this only support a subset of all the methods in time.Time
(see above) and is by design very simple. For a more advanced time mocking
library, have a look at <https://github.com/benbjohnson/clock>.
Reason for packaging: Needed by Hugo v0.99.0 and above
Bug#1012095: ITP: golang-github-bep-overlayfs -- composite Afero filesystem (Go library)
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-bep-overlayfs Version : 0.6.0-1 Upstream Author : Bjørn Erik Pedersen * URL : https://github.com/bep/overlayfs * License : Expat Programming Lang: Go Description : composite Afero filesystem (Go library) overlayfs is a composite filesystem (currently only) for Afero with similar but different semantics compared to Afero's copyOnWriteFs. Reason for packaging: Required by Hugo v0.97.0 and above.
Bug#1009664: gddrescue: Please upgrade gddrescue to 1.26
Package: gddrescue Version: 1.23-2+b1 Severity: normal X-Debbugs-Cc: f...@debian.org Hi Michael, Thank you so much for maintaining gddrescue which has helped me rescue failing disks quite a few times. GNU ddrescue 1.26 has been released, and it would be really nice if you could upgrade the Debian packaging from 1.23 to 1.26 at your convenience. Here are the links to the release announcements: * 1.24: https://lists.gnu.org/archive/html/info-gnu/2019-02/msg00012.html * 1.25: https://lists.gnu.org/archive/html/info-gnu/2020-03/msg2.html * 1.26: https://lists.gnu.org/archive/html/info-gnu/2022-01/msg00013.html Changes in version 1.24: * The new option '--command-mode' has been added. It activates a scripting interface similar to the one of ed which reads commands from the standard input and executes them, copying parts of the input file on demand. * Ddrescue now tries to create a backup copy of the mapfile, with the name .bak, every time it is going to overwrite a fsynced mapfile. On startup, ddrescue verifies that the backup mapfile (if it exists) is not a non-regular file, and that its name is not the same as infile or outfile. * It has been documented that when ddrescue finishes, the contents of any areas marked as bad-sector remain untouched in the output file. * The configure script now accepts appending options to CXXFLAGS using the syntax 'CXXFLAGS+=OPTIONS'. Changes in version 1.25: * Default constructors have been added to classes Block and Sblock. (Reported by Rosen Penev). * A failure in 'make check', happening when testing under a directory with spaces in the name, has been fixed. (Reported by David Morrison). * In rescue mode, any non-finished subsector that is now found during the initial read of the mapfile will be joined to its corresponding sector (if it is also not finished), marking the whole sector with the less processed state, so as to make sure that sub-sector data will not be discarded from a successful read during the rescue. (A subsector is a block smaller than the sector size). (Reported by David Burton). * The time needed to write the mapfile is now excluded from the mapfile save and sync intervals. (It seems that some mapfiles take 7 seconds to write). (Reported by David Burton). * Ddrescue now extends the output file using 'ftruncate' if it works, because it is slightly more efficient. * Large numbers in messages (like device sizes) are now printed in groups of 3 digits separated by underscore '_' characters to make them more readable. Changes in version 1.26: * While writing the mapfile, ddrescue now checks the return value of each call to 'fprintf' to catch any temporary failure of 'fprintf' not reported by the system when closing the file. (Hole in mapfile reported by Radomír Tomis). * Domain mapfiles may now contain unordered and overlapping blocks when '-L, --loose-domain' is specified as long as no block overlaps with other block of different status. (Suggested by Gábor Katona and Shaya Potter). * Ddrescue now shows the file name in all the diagnostics with a file involved. (Reported by Radomír Tomis). * Ddrescue now exits with status 1 on fatal read errors. (Suggested by Marco Marques). * Empty phases are now completely skipped. * Ddrescue now scrolls forward after each pass. This keeps on the screen the final status of the previous pass, making it easier to estimate the amount of work done by the current pass. (Based on a suggestion by David Morrison). * In case of error in a numerical argument to a command line option, ddrescue now shows the name of the option and the range of valid values. * The option synonyms '--*-logfile' and '--pause' have been removed and are no longer recognized. * Ddrescuelog now can convert between mapfiles and bitmaps of blocks (big and little endian). The new option '-F, --format' has been added to ddrescuelog. It selects the input format for '--create-mapfile', or the output format for '--list-blocks'. (Bitmap format proposed by Florian Sedivy). * Option '-d, --delete-if-done' of ddrescuelog no longer returns an error if the mapfile is read from standard input. Instead it behaves like '-D, --done-status' because there is nothing to delete. * 'ddrescuelog --show-status' now rounds percentages up to get the sum closer to 100%. * Three missing '#include ' have been added. (Reported by Richard Burkert). * The description of the algorithm in the manual has been improved. Many thanks! Kind regards, Anthony Fok -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.0-6-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via
Bug#1008844: gitsome gh fails to run with python3.10
Package: gitsome
Version: 0.8.0+ds-6
Severity: important
Tags: patch upstream
X-Debbugs-Cc: f...@debian.org
/usr/bin/gh provided by gitsome (as of 0.8.0+ds-6) fails to run with python3.10
which has become the default Python 3 in Debian sid:
$ gh
Traceback (most recent call last):
File "/usr/bin/gh", line 34, in
sys.exit(load_entry_point('gitsome==0.8.0', 'console_scripts', 'gh')())
File "/usr/bin/gh", line 26, in importlib_load_entry_point
return next(matches).load()
File "/usr/lib/python3.10/importlib/metadata/__init__.py", line 171, in load
module = import_module(match.group('module'))
File "/usr/lib/python3.10/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1050, in _gcd_import
File "", line 1027, in _find_and_load
File "", line 1006, in _find_and_load_unlocked
File "", line 688, in _load_unlocked
File "", line 883, in exec_module
File "", line 241, in _call_with_frames_removed
File "/usr/lib/python3/dist-packages/gitsome/main_cli.py", line 20, in
from .githubcli import GitHubCli
File "/usr/lib/python3/dist-packages/gitsome/githubcli.py", line 21, in
from .github import GitHub
File "/usr/lib/python3/dist-packages/gitsome/github.py", line 25, in
from .lib.github3 import null
File "/usr/lib/python3/dist-packages/gitsome/lib/github3/__init__.py", line
18, in
from .api import (
File "/usr/lib/python3/dist-packages/gitsome/lib/github3/api.py", line 11, in
from .github import GitHub, GitHubEnterprise
File "/usr/lib/python3/dist-packages/gitsome/lib/github3/github.py", line 13,
in
from .auths import Authorization
File "/usr/lib/python3/dist-packages/gitsome/lib/github3/auths.py", line 12,
in
from .models import GitHubCore
File "/usr/lib/python3/dist-packages/gitsome/lib/github3/models.py", line 19,
in
from .session import GitHubSession
File "/usr/lib/python3/dist-packages/gitsome/lib/github3/session.py", line 4,
in
from collections import Callable
ImportError: cannot import name 'Callable' from 'collections'
(/usr/lib/python3.10/collections/__init__.py)
This bug was reported to and fixed in Ubuntu on 2022-01-28
by Alexandre Ghiti ;
see https://bugs.launchpad.net/ubuntu/+source/gitsome/+bug/1959377
You may consider downloading his patch from
https://bugs.launchpad.net/ubuntu/+source/gitsome/+bug/1959377/+attachment/5557913/+files/debdiff_python3.10.patch
The whole Ubuntu patch with other unrelated changes is available at
https://patches.ubuntu.com/g/gitsome/gitsome_0.8.0+ds-6ubuntu1.patch
Alexandre Ghiti has also forwarded his patch upstream as PR #191:
https://github.com/donnemartin/gitsome/pull/191
Add support for python 3.10" at
Use 'collections.abc' instead of 'collections' since python 3.10 does not
accept
this syntax anymore, it has been deprecated since python 3.3.
Cheers,
Anthony
-- System Information:
Debian Release: bookworm/sid
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'oldoldstable'), (500,
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.16.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages gitsome depends on:
ii python3 3.10.4-1
ii python3-click 8.0.3-1
ii python3-colorama 0.4.4-1
ii python3-docopt0.6.2-4
ii python3-feedparser6.0.8-1
ii python3-numpydoc 1.2.1-1
ii python3-ply 3.11-5
ii python3-prompt-toolkit3.0.28-1
ii python3-pygments 2.11.2+dfsg-2
ii python3-requests 2.27.1+dfsg-1
ii python3-sigmavirus24-urltemplate 4.1.1-1
ii python3-tz2022.1-1
ii xonsh 0.11.0+dfsg-1
gitsome recommends no packages.
gitsome suggests no packages.
-- no debconf information
diff -Nru gitsome-0.8.0+ds/debian/changelog gitsome-0.8.0+ds/debian/changelog
--- gitsome-0.8.0+ds/debian/changelog 2021-11-06 17:24:54.0 +0100
+++ gitsome-0.8.0+ds/debian/changelog 2022-01-28 10:43:07.0 +0100
@@ -1,3 +1,10 @@
+gitsome (0.8.0+ds-6ubuntu1) jammy; urgency=medium
+
+ * d/patches:
+- Add support for python3.10
+
+ -- Alexandre Ghiti Fri, 28 Jan 2022 10:43:07
+0100
+
gitsome (0.8.0+ds-6) unstable; urgency=medium
* Fix FTBFS issue (Closes: #997316)
diff -Nru gitsome-0.8.0+ds/debian/patches/python3.10-support.patch
gitsome-0.8.0+ds/debian/patches/python3.10-support.patch
---
Bug#1008777: ITP: cobra-cli -- Cobra CLI tool to generate Go applications and commands
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: cobra-cli Version : 1.3.0-1 Upstream Author : Steve Francia * URL : https://github.com/spf13/cobra-cli * License : Apache-2.0 Programming Lang: Go Description : Cobra CLI tool to generate Go applications and commands Cobra provides its own program that will create your Go application and add any commands you want. It's the easiest way to incorporate Cobra into your application. Reason for packaging: "cobra" has been dropped from golang-github-spf13-cobra upstream since 1.4.0, and has been moved to https://github.com/spf13/cobra-cli and renamed as "cobra-cli"
Bug#1005858: gh,gitsome: File conflict, both ship /usr/bin/gh
Hi everyone, On Sat, Feb 26, 2022 at 7:09 PM Paul Wise wrote: > > Control: forwarded -1 https://github.com/donnemartin/gitsome/issues/177 > > On Sat, 26 Feb 2022 23:43:14 +0800 SZ Lin (林上智) wrote: > > > The "gitsome" has used "gh" since 2017, and thus would you mind renaming > > the "gh" in your package to avoid the conflict issue? > > Since gh is the official GitHub client, probably it should retain "gh" > and gitsome should move to "git some" or similar, as I have suggested > in the above upstream issue. The only commentor there agreed with me. Thank you all for the discussion and attempt at resolving the filename conflict. Judging from gitsome's GitHub repo being left stagnant since May 2019, with Issues and PRs unanswered, despite the fact that upstream author is still active daily on GitHub, I doubt we'll see a reply from gitsome's author anytime soon. Automation scripts are relying on the GitHub CLI command to be named as "gh", so renaming /usr/bin/gh in "gh" to something else is out of the question too. Rather than keeping this "Serious" bug open and keeping both gitsome and gh out of Debian testing, I think the simple solution of having gh "Conflicts: gitsome", which is one of the option specified in https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts, would suffice for now, allowing both packages to (re-)enter testing in the meantime. SZ, if you think the use of alternatives (such that both the gitsome and gh packages can be installed simultaneously) is a better solution, I'd be happy to work something out with you too. Cheers, Anthony
Bug#1006634: ITP: golang-github-hairyhenderson-go-codeowners -- A Go package that finds and parses GitHub CODEOWNERS files
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-hairyhenderson-go-codeowners Version : 0.2.2+git20201026.cdc7c07-1 Upstream Author : Dave Henderson * URL : https://github.com/hairyhenderson/go-codeowners * License : Expat Programming Lang: Go Description : Go package that finds and parses GitHub CODEOWNERS files go-codeowners is a Go package that finds and parses CODEOWNERS files; see https://help.github.com/articles/about-codeowners/ . Features: . * operates on local repos * doesn't require a cloned repo (i.e. doesn't need a .git directory to be present at the repo's root) * can be called from within a repo (doesn't have to be at the root) * will find CODEOWNERS files in all documented locations: the repo's root, docs/, and .github/ (or .gitlab/ for GitLab repos) Reason for packaging: Needed by hugo >= v0.93.0
Bug#1006430: ITP: golang-github-bep-goat -- Render ASCII art as SVG diagrams
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-bep-goat Version : 0.5.0-1 Upstream Author : Bryce Lampe, Bjørn Erik Pedersen * URL : https://github.com/bep/goat * License : Expat Programming Lang: Go Description : Render ASCII art as SVG diagrams GoAT: Go ASCII Tool . This is a Go implementation of markdeep.mini.js's ASCII diagram generation. It renders ASCII art as SVG diagrams. Reason for packaging: Needed by hugo >= 0.93.0
Bug#1003548: transition: libwebp
On Sun, Feb 6, 2022 at 1:30 PM Jeff Breidenbach wrote: > The package has been corrected with version 1.2.1-6 which has > been uploaded to experimental. > > Please let us know if we can proceed with the upload to unstable. Also > a binNMU rebuild of reverse dependencies would be required afterwards. Hurray! That is great news! Thank you for your great work with libwebp 1.2.1! I am waiting for the new libwebp 1.2.1 to land in Debian unstable too! Cheers, Anthony
Bug#1004925: inkscape: Wrong and inconsistent linespacing (AppImage and Snap OK)
Package: inkscape Version: 1.1.1-3 Severity: normal X-Debbugs-Cc: f...@debian.org Hi! As reported on Reddit: https://www.reddit.com/r/Inkscape/comments/rkjktp/for_come_reason_my_line_spacing_is_inconsistent/ The linespacing after the 1st line "seems" OK (but actually too large), but linespacing in subsequent lines are even larger. I am running into the same issue with Debian Inkscape .deb package. When I open the same file (with multiline text objects) with: * AppImage (Inkscape-3bf5ae0-x86_64.AppImage, i.e. 1.1.1) * Windows (same version, 1.1.1, 3bf5ae0d25, 2021-09-20) * Snap (1.1.1-26b7af14f2-2022-01-19) the linespacing is actually correct and consistent across all lines. So, I just come to the realization that an Inkscape file that seems to look OK when open with Debian's Inkscape would actually look wrong everywhere else. I was lucky that a recent file that I sent for CNC routing purposes, I had the text objects converted to paths first Many thanks for looking into this! Anthony -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-3-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages inkscape depends on: ii lib2geom1.1.0 1.1-2+b1 ii libatkmm-1.6-1v5 2.28.2-1 ii libboost-filesystem1.74.0 1.74.0-14 ii libc6 2.33-5 ii libcairo2 1.16.0-5 ii libcairomm-1.0-1v5 1.12.2-4 ii libcdr-0.1-1 0.1.6-2 ii libdbus-glib-1-2 0.112-2 ii libfontconfig1 2.13.1-4.3 ii libfreetype6 2.11.1+dfsg-1 ii libgc1 1:8.0.6-1.1 ii libgcc-s1 11.2.0-14 ii libgdk-pixbuf-2.0-02.42.6+dfsg-2 ii libglib2.0-0 2.70.3-1 ii libglibmm-2.4-1v5 2.66.2-2+b1 ii libgomp1 11.2.0-14 ii libgsl27 2.7.1+dfsg-3 ii libgspell-1-2 1.9.1-2 ii libgtk-3-0 3.24.31-1 ii libgtkmm-3.0-1v5 3.24.5-1 ii libharfbuzz0b 2.7.4-1 ii libjpeg62-turbo1:2.1.2-1 ii liblcms2-2 2.12~rc1-2 ii libmagick++-6.q16-88:6.9.11.60+dfsg-1.3 ii libpango-1.0-0 1.50.3+ds1-4 ii libpangocairo-1.0-01.50.3+ds1-4 ii libpangoft2-1.0-0 1.50.3+ds1-4 ii libpangomm-1.4-1v5 2.46.1-1 ii libpng16-161.6.37-3 ii libpoppler-glib8 20.09.0-3.1 ii libpoppler102 20.09.0-3.1 ii libpotrace01.16-2 ii libreadline8 8.1.2-1 ii librevenge-0.0-0 0.0.4-6+b1 ii librsvg2-common2.52.5+dfsg-3+b1 ii libsigc++-2.0-0v5 2.10.4-2 ii libsoup2.4-1 2.74.2-3 ii libstdc++6 11.2.0-14 ii libvisio-0.1-1 0.1.7-1+b1 ii libwpg-0.3-3 0.3.3-1 ii libx11-6 2:1.7.2-2+b1 ii libxml22.9.12+dfsg-5+b1 ii libxslt1.1 1.1.34-4 ii python33.9.8-1 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages inkscape recommends: ii aspell 0.60.8-4 ii fig2dev 1:3.2.8b-1 ii imagemagick 8:6.9.11.60+dfsg-1.3 ii imagemagick-6.q16 [imagemagick] 8:6.9.11.60+dfsg-1.3 ii libimage-magick-perl 8:6.9.11.60+dfsg-1.3 ii libwmf-bin 0.2.8.4-17+b1 ii python3-lxml 4.7.1-1 ii python3-numpy1:1.21.5-1 ii python3-scour0.38.2-2 Versions of packages inkscape suggests: pn dia pn inkscape-tutorials pn libsvg-perl ii pstoedit 3.78-1 pn python3-uniconvertor ii ruby 1:2.7.6 -- no debconf information
Bug#1002898: ITP: golang-github-cli-shurcool-graphql -- GraphQL client implementation for Go (GitHub CLI fork)
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-cli-shurcool-graphql Version : 0.0.1-1 Upstream Author : Dmitri Shuralyov * URL : https://github.com/cli/shurcooL-graphql * License : Expat Programming Lang: Go Description : GraphQL client implementation for Go (GitHub CLI fork) Package graphql provides a GraphQL client implementation for Go. It is forked from https://github.com/shurcooL/graphql for GitHub CLI "gh". Reason for packaging: Needed by GitHub CLI "gh"
Bug#1002810: ITP: golang-github-meowgorithm-babylogger -- Go HTTP logger middleware, for babies
Hi josch, On Wed, Dec 29, 2021 at 12:15 AM Johannes Schauer Marin Rodrigues wrote: > On Tue, 28 Dec 2021 23:56:00 -0700 "Anthony Fok" wrote: > > > Babylogger is a Go HTTP logger middleware, for babies. > > I read this description and I read upstream's README but I cannot figure out > in > what way this software is for babies. Please adjust the description of the > final package to make this clear. Good question! I think it is either tongue-in-cheek or marketing-speak by upstream, probably as a series (Babyenv, Babylogger), or maybe to suggest how easy it is to use, and I followed along. That said, I agree that it can certainly cause confusion. I have already uploaded the package though (within minutes of sending the ITP), but I will revise the package description for the source-only upload. Thanks again! Cheers, Anthony
Bug#1002812: ITP: golang-goji -- minimalistic and flexible HTTP request multiplexer for Go
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-goji Version : 2.0.2-1 Upstream Author : Goji * URL : https://github.com/goji/goji (goji.io) * License : Expat Programming Lang: Go Description : minimalistic and flexible HTTP request multiplexer for Go Goji is a HTTP request multiplexer, similar to net/http.ServeMux. It compares incoming requests to a list of registered Patterns and dispatches to the http.Handler that corresponds to the first matching Pattern. Goji also supports Middleware (composable shared functionality applied to every request) and uses the standard context package to store request-scoped values. Reason for packaging: Needed by github.com/charmbracelet/charm Note: This is a new version of Goji that supersedes github.com/zenazn/goji v1.0.1 (packaged for Debian as golang-github-zenazn-goji)
Bug#1002810: ITP: golang-github-meowgorithm-babylogger -- Go HTTP logger middleware, for babies
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-meowgorithm-babylogger Version : 1.2.0-1 Upstream Author : Christian Rocha * URL : https://github.com/meowgorithm/babylogger * License : Expat Programming Lang: Go Description : Go HTTP logger middleware, for babies Babylogger is a Go HTTP logger middleware, for babies. . It has been used with Goji (http://goji.io) and the Go standard library, but it should work with any multiplexer worth its salt, i.e. any multiplexer compatible with the standard library. . Note that ANSI escape sequences (read: colors) will be stripped from the output when the logger is not running in a terminal. For example, log files won't contain any sort of ANSI intended for color output. . Also note that for accurate response time logging Babylogger should be the first middleware called. Reason for packaging: Needed by github.com/charmbracelet/charm
Bug#1002809: ITP: golang-github-calmh-randomart -- generates OpenSSH-style randomart
Package: wnpp
Severity: wishlist
Owner: Anthony Fok
* Package name: golang-github-calmh-randomart
Version : 1.1.0-1
Upstream Author : Jakob Borg
* URL : https://github.com/calmh/randomart
* License : Expat
Programming Lang: Go
Description : generates OpenSSH-style randomart (Go library)
Go package randomart generates OpenSSH style "randomart" images
based on key fingerprints.
.
Example:
.
data := []byte{ 0x9b, 0x4c, 0x7b, 0xce, 0x7a, 0xbd, 0x0a, 0x13,
0x61, 0xfb, 0x17, 0xc2, 0x06, 0x12, 0x0c, 0xed }
ra := randomart.Generate(data, "RSA 2048")
fmt.Println(ra)
.
+--[ RSA 2048 ]---+
|.+. |
| o. |
| .. +|
| Eo = |
|S + .|
| o B . . |
|B o..|
| *...|
|.o+... |
+-+
Reason for packaging:
Needed by github.com/charmbracelet/charm
Bug#1002808: ITP: golang-github-muesli-toktok -- typo/error resilient, human-readable token generator (Go library)
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-muesli-toktok Version : 0.0~git20210519.2b0817e-1 Upstream Author : Christian Muehlhaeuser * URL : https://github.com/muesli/toktok * License : TODO Programming Lang: Go Description : typo/error resilient, human-readable token generator (Go library) Go package toktok is a human-friendly token generator. It creates tokens which avoid characters that can be easily misinterpreted, like '1' and 'I' or '8' and 'B', as well as repeated characters within the token. It also compares newly generated tokens to all previously generated ones and guarantees a safety distance between the tokens, so they become resilient to typos or other human entry errors. Reason for packaging: Needed by github.com/charmbracelet/charm
Bug#1002806: ITP: golang-github-muesli-sasquatch -- simple data encryption library for Go
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-muesli-sasquatch Version : 0.0~git20210519.30aff9d-1 Upstream Author : Christian Muehlhaeuser * URL : https://github.com/muesli/sasquatch * License : BSD-3-clause Programming Lang: Go Description : simple data encryption library for Go A simple data encryption library, heavily inspired by @Benjojo12 and @FiloSottile's fantastic "age" project. . Features: . * Multiple recipients * Supports encrypting with your existing SSH keys / ssh-agent * Convenient API . Crypto Backends: . * ssh-rsa * ssh-ed25519 * ssh-agent signing challenge (excluding ECDSA identities, as ECDSA signatures aren't deterministic) * scrypt / password Reason for packaging: Needed by golang-github-charmbracelet-charm
Bug#1002804: ITP: golang-github-charmbracelet-wish -- Make SSH apps, just like that! (Go library)
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-charmbracelet-wish Version : 0.1.1-1 Upstream Author : Charm * URL : https://github.com/charmbracelet/wish * License : Expat Programming Lang: Go Description : Make SSH apps, just like that! (Go library) Wish is an SSH server with sensible defaults and a collection of middleware that makes building SSH apps easy. Wish is built on gliderlabs/ssh and should be easy to integrate into any existing projects. . SSH is an excellent platform to build remotely accessible applications on. It offers secure communication without the hassle of HTTPS certificates, it has user identification with SSH keys and it's accessible from anywhere with a terminal. Powerful protocols like Git work over SSH and you can even render TUIs directly over an SSH connection. Reason for packaging: Needed by Glow (github.com/charmbracelet/glow) etc.
Bug#1002000: ITP: golang-github-charmbracelet-keygen -- SSH key pair generator (Go library)
Package: wnpp
Severity: wishlist
Owner: Anthony Fok
* Package name: golang-github-charmbracelet-keygen
Version : 0.1.2-1
Upstream Author : Charm
* URL : https://github.com/charmbracelet/keygen
* License : Expat
Programming Lang: Go
Description : SSH key pair generator (Go library)
Go package keygen is an SSH key pair generator.
Supports generating RSA and Ed25519 keys.
.
Example
.
k, err := NewWithWrite(".ssh", "my_awesome_key", []byte(""), key.Ed25519)
if err != nil {
fmt.Printf("error creating SSH key pair: %v", err)
os.Exit(1)
}
Bug#1001997: ITP: golang-github-charmbracelet-bubbles -- TUI components for Bubble Tea (Go library)
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-charmbracelet-bubbles Version : 0.9.0-1 Upstream Author : Charmbracelet, Inc. * URL : https://github.com/charmbracelet/bubbles * License : Expat Programming Lang: Go Description : TUI components for Bubble Tea (Go library) Go package bubbles provides some components for Bubble Tea applications. These components are used in production in Glow, Charm and many other applications. . Spinner . A spinner, useful for indicating that some kind an operation is happening. There are a couple default ones, but you can also pass your own ”frames.” . Text Input . A text input field, akin to an in HTML. Supports unicode, pasting, in-place scrolling when the value exceeds the width of the element and the common, and many customization options. . Progress . A simple, customizable progress meter, with optional animation via Harmonica. Supports solid and gradient fills. The empty and filled runes can be set to whatever you'd like. The percentage readout is customizable and can also be omitted entirely. . Paginator . A component for handling pagination logic and optionally drawing pagination UI. Supports "dot-style" pagination (similar to what you might see on iOS) and numeric page numbering, but you could also just use this component for the logic and visualize pagination however you like. . Viewport . A viewport for vertically scrolling content. Optionally includes standard pager keybindings and mouse wheel support. A high performance mode is available for applications which make use of the alternate screen buffer. . This component is well complemented with Reflow for ANSI-aware indenting and text wrapping. . List . A customizable, batteries-included component for browsing a set of items. Features pagination, fuzzy filtering, auto-generated help, an activity spinner, and status messages, all of which can be enabled and disabled as needed. Extrapolated from Glow. . Help . A customizable horizontal mini help view that automatically generates itself from your keybindings. It features single and multi-line modes, which the user can optionally toggle between. It will truncate gracefully if the terminal is too wide for the content. . Key . A non-visual component for managing keybindings. It’s useful for allowing users to remap keybindings as well as generating help views corresponding to your keybindings. Reason for packaging: Prerequisite for Glow, Charm, etc.
Bug#1001888: RM: renpy -- RoQA; depends on Python 2 and deprecated libavresample, RC-buggy
On Sat, Dec 18, 2021 at 4:51 AM Sebastian Ramacher wrote: > Please remove renpy from unstable. It was not included in bullseye since > it still depends on Python 2 (#938351). While there was some initial > progress to port it to Python 3, nothing seems to be happening since > over a year. See also https://github.com/renpy/renpy/issues/1098 which > seems to be stalled since 2019. renpy also needs to be updated from > libavresample to libswresample (#971325). So please remove it from > unstable. Well, more activities are happening now: Issue #2003: Python 3 Support https://github.com/renpy/renpy/issues/2003 with the lead developer @renpytom promising in September 2021 that he'd "expect python3 to happen late this year or early next year." And, according to https://github.com/renpy/renpy/commits/master, @renpytom is at long last finally actively working on getting Python 3 to work. So, perhaps give them a bit more time to get RenPy with Python 3 support released? Cheers, Anthony
Bug#1001847: ITP: golang-github-charmbracelet-bubbletea -- powerful little TUI framework for Go
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-charmbracelet-bubbletea Version : 0.19.1-1 Upstream Author : Charmbracelet, Inc. * URL : https://github.com/charmbracelet/bubbletea * License : Expat Programming Lang: Go Description : powerful little TUI framework for Go Bubble Tea is the fun, functional and stateful way to build terminal apps. A Go framework based on The Elm Architecture. Bubble Tea is well-suited for simple and complex terminal applications, either inline, full-window, or a mix of both. . Bubble Tea is in use in production and includes a number of features and performance optimizations we’ve added along the way. Among those is a standard framerate-based renderer, a renderer for high-performance scrollable regions which works alongside the main renderer, and mouse support. Reason for packaging: Prerequisite for Glow @ github.com/charmbracelet/glow, etc. TODO: perhaps reasoning
Bug#1001327: ITP: golang-github-charmbracelet-harmonica -- simple, efficient spring animation library
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-charmbracelet-harmonica Version : 0.1.0-1 Upstream Authors: Ryan Juckett; Charmbracelet, Inc. * URL : https://github.com/charmbracelet/harmonica * License : Zlib, Expat Programming Lang: Go Description : simple, efficient spring animation library for Go Go package harmonica is a simple, efficient spring animation library for smooth, natural motion. . It even works well on the command line. . This library is a fairly straightforward port of Ryan Juckett’s excellent damped simple harmonic oscillator originally writen in C++ in 2008 and published in 2012. Ryan’s writeup on the subject is fantastic; see https://www.ryanjuckett.com/damped-springs/ Reason for packaging: Prerequisite for Bubbles @ https://github.com/charmbracelet/bubbles to be packaged as golang-github-charmbracelet-bubbles
Bug#1001310: ITP: golang-github-charmbracelet-lipgloss -- style definitions for nice terminal layouts
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-charmbracelet-lipgloss Version : 0.4.0-1 Upstream Author : Charm * URL : https://github.com/charmbracelet/lipgloss * License : Expat Programming Lang: Go Description : style definitions for nice terminal layouts Go package lipgloss provides style definitions for nice terminal layouts. Built with TUIs in mind. . Lip Gloss takes an expressive, declarative approach to terminal rendering. Users familiar with CSS will feel at home with Lip Gloss. Reason for packaging: Prerequsite for e.g. github.com/muesli/gitty
Bug#1001304: ITP: golang-github-muesli-ansi -- raw ANSI sequence helpers for Go
Package: wnpp
Severity: wishlist
Owner: Anthony Fok
* Package name: golang-github-muesli-ansi
Version : 0.0~git20211031.c9f0611-1
Upstream Author : Christian Muehlhaeuser
* URL : https://github.com/muesli/ansi
* License : Expat
Programming Lang: Go
Description : raw ANSI sequence helpers for Go
Package ansi provides raw ANSI sequence helpers for Go.
.
ANSI Writer
.
import "github.com/muesli/ansi"
.
w := ansi.Writer{Forward: os.Stdout}
w.Write([]byte("\x1b[31mHello, world!\x1b[0m"))
w.Close()
.
Compressor
.
The ANSI compressor eliminates unnecessary/redundant ANSI sequences.
.
import "github.com/muesli/ansi/compressor"
.
w := compressor.Writer{Forward: os.Stdout}
w.Write([]byte("\x1b[31mHello, world!\x1b[0m"))
w.Close()
Reason for packaging:
Prerequisite for golang-github-charmbracelet-bubbletea
@ https://github.com/charmbracelet/bubbletea
Bug#1001260: ITP: golang-github-meowgorithm-babyenv -- Go environment var parsing, for babies
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-meowgorithm-babyenv Version : 1.3.1-1 Upstream Author : Christian Rocha * URL : https://github.com/meowgorithm/babyenv * License : Expat Programming Lang: Go Description : Go environment var parsing, for babies Package babyenv collects environment variables and places them in corresponding struct fields. It aims to reduce the boilerplate in reading data from the environment. Reason for packaging: Prerequisite for Glow @ https://github.com/charmbracelet/glow TODO: perhaps reasoning
Bug#1001259: ITP: golang-github-muesli-go-app-paths -- retrieve platform-specific paths (app-data, cache, config, etc.)
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-muesli-go-app-paths Version : 0.2.1-1 Upstream Author : Christian Muehlhaeuser * URL : https://github.com/muesli/go-app-paths * License : Expat Programming Lang: Go Description : retrieve platform-specific paths (app-data, cache, config, etc.) The go-app-paths package retrieves platform-specific paths (such as directories for app-data, cache, config, and logs). It is fully compliant with the XDG Base Directory Specification on Unix, but also provides implementations for macOS and Windows systems. Reason for packaging: Prerequisite for Glow, https://github.com/charmbracelet/glow
Bug#1001231: ITP: golang-github-muesli-gitcha -- Go helpers to work with git repositories
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-muesli-gitcha Version : 0.2.0-1 Upstream Author : Christian Muehlhaeuser * URL : https://github.com/muesli/gitcha * License : Expat Programming Lang: Go Description : Go helpers to work with git repositories The gitcha package provides Go helpers to work with git repositories. . Examples of things gitcha can do: * return the directory of the git repository path is a member of: * find files from list in path, respecting .gitignores it finds * find files, excluding any matches in a given set of ignore Reason for packaging: Prerequisite for Glow (https://github.com/charmbracelet/grow)
Bug#1001226: ITP: golang-github-segmentio-ksuid -- K-Sortable Globally Unique IDs
Package: wnpp
Severity: wishlist
Owner: Anthony Fok
* Package name: golang-github-segmentio-ksuid
Version : 1.0.4-1
Upstream Author : Segment (https://segment.com/)
* URL : https://github.com/segmentio/ksuid
* License : Expat
Programming Lang: Go
Description : K-Sortable Globally Unique IDs
ksuid is an efficient, comprehensive, battle-tested Go library for
generating and parsing a specific kind of globally unique identifier
called a *KSUID*. This library serves as its reference implementation.
.
What is a KSUID?
.
KSUID is for K-Sortable Unique IDentifier. It is a kind of globally
unique identifier similar to a RFC 4122 UUID
(https://en.wikipedia.org/wiki/Universally_unique_identifier), built
from the ground-up to be "naturally" sorted by generation timestamp
without any special type-aware logic.
.
In short, running a set of KSUIDs through the UNIX sort command will
result in a list ordered by generation time.
.
Why use KSUIDs?
.
There are numerous methods for generating unique identifiers, so why
KSUID?
.
1. Naturally ordered by generation time
2. Collision-free, coordination-free, dependency-free
3. Highly portable representations
.
Even if only one of these properties are important to you, KSUID is a
great choice! :) Many projects chose to use KSUIDs *just* because the
text representation is copy-and-paste friendly.
.
1. Naturally Ordered By Generation Time
.
Unlike the more ubiquitous UUIDv4, a KSUID contains a timestamp
component that allows them to be loosely sorted by generation time. This
is not a strong guarantee (an invariant) as it depends on wall clocks,
but is still incredibly useful in practice. Both the binary and text
representations will sort by creation time without any special sorting
logic.
.
2. Collision-free, Coordination-free, Dependency-free
.
While RFC 4122 UUIDv1s *do* include a time component, there aren't
enough bytes of randomness to provide strong protection against
collisions (duplicates). With such a low amount of entropy, it is
feasible for a malicious party to guess generated IDs, creating a
problem for systems whose security is, implicitly or explicitly,
sensitive to an adversary guessing identifiers.
.
To fit into a 64-bit number space, Snowflake IDs
(https://blog.twitter.com/2010/announcing-snowflake) and its derivatives
require coordination to avoid collisions, which significantly increases
the deployment complexity and operational burden.
.
A KSUID includes 128 bits of pseudorandom data ("entropy"). This number
space is 64 times larger than the 122 bits used by the well-accepted RFC
4122 UUIDv4 standard. The additional timestamp component can be
considered "bonus entropy" which further decreases the probability of
collisions, to the point of physical infeasibility in any practical
implementation.
.
3. Highly Portable Representations
.
The text *and* binary representations are lexicographically sortable,
which allows them to be dropped into systems which do not natively
support KSUIDs and retain their time-ordered property.
.
The text representation is an alphanumeric base62 encoding, so it "fits"
anywhere alphanumeric strings are accepted. No delimiters are used, so
stringified KSUIDs won't be inadvertently truncated or tokenized when
interpreted by software that is designed for human-readable text, a
common problem for the text representation of RFC 4122 UUIDs.
.
How do KSUIDs work?
.
Binary KSUIDs are 20-bytes: a 32-bit unsigned integer UTC timestamp and a
128-bit randomly generated payload. The timestamp uses big-endian
encoding, to support lexicographic sorting. The timestamp epoch is
adjusted to May 13th, 2014, providing over 100 years of life. The
payload is generated by a cryptographically-strong pseudorandom number
generator.
.
The text representation is always 27 characters, encoded in alphanumeric
base62 that will lexicographically sort by timestamp.
.
High Performance
.
This library is designed to be used in code paths that are performance
critical. Its code has been tuned to eliminate all non-essential
overhead. The KSUID type is derived from a fixed-size array, which
eliminates the additional reference chasing and allocation involved in a
variable-width type.
.
The API provides an interface for use in code paths which are sensitive
to allocation. For example, the Append method can be used to parse the
text representation and replace the contents of a KSUID value without
additional heap allocation.
.
All public package level "pure" functions are concurrency-safe, protected
by a global mutex. For hot loops that generate a large amount of KSUIDs
from a single Goroutine, the Sequence type is provided to elide the
potential contention.
.
By default, out of an abundance of caution, the cryptographically-secure
PRNG is used to generate the random bits of a KS
Bug#1001212: ITP: golang-github-muhammadmuzzammil1998-jsonc -- JSON with comments for Go!
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-muhammadmuzzammil1998-jsonc Version : 0.0~git20201229.615b091-1 Upstream Author : Muhammad Muzzammil * URL : https://github.com/muhammadmuzzammil1998/jsonc * License : Expat Programming Lang: Go Description : JSON with comments for Go! JSONC is a superset of JSON which supports comments. JSON formatted files are readable to humans but the lack of comments decreases readability. With JSONC, you can use block (/* */) and single line (//) comments to describe the functionality. Microsoft VS Code also uses this format in their configuration files like settings.json, keybindings.json, launch.json, etc. . What this package offers . "JSONC for Go" offers ability to convert and unmarshal JSONC to pure JSON. It also provides functionality to read JSONC file from disk and return JSONC and corresponding JSON encoding to operate on. However, it only provides a one-way conversion. That is, you can not generate JSONC from JSON. Read documentation (DOCUMENTATION.md) for detailed examples. Reason for packaging: Needed by GitHub CLI (gh), see #951374
Bug#1001089: ITP: golang-github-clbanning-mxj -- mxj - to/from maps, XML and JSON (Go library)
Package: wnpp
Severity: wishlist
Owner: Anthony Fok
* Package name: golang-github-clbanning-mxj
Version : 2.5.5-1
Upstream Author : Charles Banning
* URL : https://github.com/clbanning/mxj
* License : Expat
Programming Lang: Go
Description : mxj - to/from maps, XML and JSON (Go library)
Decode/encode XML to/from map[string]interface{} (or JSON) values,
and extract/modify values from maps by key or key-path, including wildcards.
.
mxj supplants the legacy x2j and j2x packages.
If you want the old syntax, use mxj/x2j and mxj/j2x packages.
Reason for packaging: Needed by the upcoming Hugo 0.90.0 and up
Bug#1000527: wireplumber: Desktop audio capture not working after upgrading to 0.4.5
Package: wireplumber Version: 0.4.5-1 Severity: normal Tags: upstream X-Debbugs-Cc: f...@debian.org After upgrading wireplumber from 0.4.4-1 to 0.4.5-1, "Desktop Audio" captured from OBS Studio became abnormal, either getting intermittent bursts of audio (from desktop?) intermingled with silence, or getting audio identical to microphone input. Once I downgrade to 0.4.4-1 and run "systemctl --user restart wireplumber", OBS "Desktop Audio" capture becomes normal again. So, for about a week now, I have been using the older wireplumber 0.4.4 as a workaround. I searched about this issue on the Internet and didn't find other people complaining about 0.4.5 specifically. Eventually, I opened up pavucontrol, opened the Recording tab, and began to see what the problem is. With OBS Studio running, capturing both "Desktop Audio" and "Mic/Aux", I see the difference between WirePlumber 0.4.4 and 0.4.5: * WirePlumber 0.4.4 (normal behaviour): + OBS: Desktop Audio from Monitor of Built-in Audio Analog Stereo + OBS: Mic/Auxfrom Built-in Audio Analog Stereo * WirePlumber 0.4.5 (wrong behaviour): + OBS: Desktop Audio from Built-in Audio Analog Stereo + OBS: Mic/Auxfrom Built-in Audio Analog Stereo With WirePlumber 0.4.5, manually changing "Built-in Audio Analog Stereo" to "Monitor of Built-in Audio Analog Stereo" allows me to properly capture Desktop Audio again. Problem is, after I restart OBS Studio, pavucontrol then shows both Desktop Audio and Mic/Aux capturing from "Monitor of Built-in Audio Analog Stereo", and I have to manually fix "OBS: Mic/Aux" in pavucontrol to use "Built-in Audio Analog Stereo". But then upon the next restart of OBS Studio, "OBS: Desktop Audio" is capturing my microphone again. It seems that WirePlumber 0.4.5 somehow got the different input sources tangled? No such problem at all with WirePlumber 0.4.4 or with pipewire-media-session. Thanks in advance! Cheers, Anthony -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wireplumber depends on: ii init-system-helpers 1.60 ii libc6 2.32-4 ii libglib2.0-0 2.70.1-1 ii libpipewire-0.3-0 0.3.40-1 ii libwireplumber-0.4-0 0.4.5-1 ii pipewire 0.3.40-1 Versions of packages wireplumber recommends: ii pipewire-pulse 0.3.40-1 wireplumber suggests no packages. -- no debconf information
Bug#998474: ITP: golang-github-djherbis-atime -- file access times (atime) for #golang
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-djherbis-atime Version : 1.1.0-1 Upstream Author : Dustin H * URL : https://github.com/djherbis/atime * License : Expat Programming Lang: Go Description : file access times (atime) for #golang File Access Times for #golang . Go has a hidden atime function for most platforms; this repo makes it accessible. . Looking for ctime or btime? Checkout https://github.com/djherbis/times, packaged as golang-github-djherbis-times-dev Reason for packaging: Needed by golang-github-tdewolff-minify (>= 2.9.22)
Bug#996938: ITP: golang-github-pelletier-go-toml.v2 -- Go library for the TOML file format
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-pelletier-go-toml.v2 Version : 2.0.0~beta3-1 Upstream Author : Thomas Pelletier * URL : https://github.com/pelletier/go-toml/tree/v2 * License : Expat, Apache-2.0 Programming Lang: Go Description : Go library for the TOML file format go-toml v2 is a Go library for the TOML format. It supports TOML (Tom's Obvious, Minimal Language) version v1.0.0. . Features: . Stdlib behavior As much as possible, this library is designed to behave similarly as the standard library's encoding/json. . Performance While go-toml favors usability, it is written with performance in mind. Most operations should not be shockingly slow. . Strict mode Decoder can be set to "strict mode", which makes it error when some parts of the TOML document was not prevent in the target structure. This is a great way to check for typos. . Contextualized errors When decoding errors occur, go-toml returns DecodeError), which contains a human readable contextualized version of the error. . Local date and time support TOML supports native local date/times. It allows to represent a given date, time, or date-time without relation to a timezone or offset. To support this use-case, go-toml provides LocalDate, LocalTime, and LocalDateTime. Those types can be transformed to and from time.Time, making them convenient yet unambiguous structures for their respective TOML representation. Reason for packaging: Needed by hugo (>= 0.87.0)
Bug#914315: libwebp-dev: New versions fix disclosed heap use-after-free
On Sat, Aug 7, 2021 at 3:00 PM Jeff Breidenbach wrote: > Maintainer is "less active" but still in good contact with upstream. > I was going to package the latest version several months ago, but > there was a soname bump and transitions were not allowed due to > Debian's release cycle. Happy to work with anyone on updating webp. Hi Jeff, I am happy to work with you on updating webp, especially now Hugo the static website generator (>= 0.83) now depends on libwebp for WebP support. Please let me know the best way to collaborate. Cheers, Anthony
Bug#994669: ITP: golang-github-pkg-diff -- create, modify, and print diffs (Go module)
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-pkg-diff Version : 0.0~git20210226.20ebb0f-1 Upstream Author : Josh Bleecher Snyder * URL : https://github.com/pkg/diff * License : BSD-3-clause Programming Lang: Go Description : create, modify, and print diffs (Go module) Module github.com/pkg/diff can be used to create, modify, and print diffs. . The top level package, `diff`, contains convenience functions for the most common uses. . The subpackages provide very fine-grained control over every aspect: . * `myers` creates diffs using the Myers diff algorithm. * `edit` contains the core diff data types. * `ctxt` provides tools to reduce the amount of context in a diff. * `write` provides routines to write diffs in standard formats. Reason for packaging: Prerequisite for golang-github-rogpeppe-go-internal >= 1.8.0
Bug#993356: golang-go: Bump version to Go 1.16
Hi Gregor, On Tue, Aug 31, 2021 at 4:27 AM Gregor Riepl wrote: > Package: golang-go > Version: 2:1.15~1 > Severity: wishlist > X-Debbugs-Cc: onit...@gmail.com > > Dear Maintainer, > > Please bump the version of the package to 1.16. > > bookworm already includes 1.16, while the upstream stable version is 1.17. > It would be very helpful to have the default Go binary point to 1.16 now. I agree, and I have been personally waiting for it too. > Are there any bugs that prevent updating the default? I don't think there is any, besides the fact that everyone has been busy and hadn't gotten around to it yet? :-) So, I went ahead and upgraded it for the very first time. 2:1.16~1 has just been uploaded. Hope I didn't introduce any new bugs! Haha! > Thank you very much. You're very welcome! Cheers, Anthony
Bug#993709: Fwd: golang-github-gabriel-vasile-mimetype_1.3.1-1_amd64.changes is NEW
Control: tags -1 pending Control: block 993442 by -1 -- Forwarded message - From: Debian FTP Masters Date: Sun, Sep 5, 2021 at 2:48 AM Subject: golang-github-gabriel-vasile-mimetype_1.3.1-1_amd64.changes is NEW To: Debian Go Packaging Team , Anthony Fok binary:golang-github-gabriel-vasile-mimetype-dev is NEW. binary:golang-github-gabriel-vasile-mimetype-dev is NEW. source:golang-github-gabriel-vasile-mimetype is NEW. Your package has been put into the NEW queue, which requires manual action from the ftpteam to process. The upload was otherwise valid (it had a good OpenPGP signature and file hashes are valid), so please be patient. Packages are routinely processed through to the archive, and do feel free to browse the NEW queue[1]. If there is an issue with the upload, you will receive an email from a member of the ftpteam. If you have any questions, you may reply to this email. [1]: https://ftp-master.debian.org/new.html or https://ftp-master.debian.org/backports-new.html for *-backports
Bug#993709: ITP: golang-github-gabriel-vasile-mimetype -- fast Go library for detecting MIME types and extensions based on magic numbers
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-gabriel-vasile-mimetype Version : 1.3.1-1 Upstream Author : Gabriel Vasile * URL : https://github.com/gabriel-vasile/mimetype * License : Expat Programming Lang: Go Description : fast Go library for detecting MIME types and extensions based on magic numbers github.com/gabriel-vasile/mimetype is a Go package for detecting MIME types and extensions based on magic numbers. . Goroutine safe, extensible, no C bindings . Features • fast and precise MIME type and file extension detection • long list of supported MIME types • posibility to extend with other file formats • common file formats are prioritized • safe for concurrent usage Reason for packaging: golang-github-gabriel-vasile-mimetype-dev is a prerequisite for gh (GitHub CLI).
Bug#979471: Fwd: golang-github-aymerick-douceur_0.2.0-1_amd64.changes is NEW
Control: tags -1 pending Hi Federico, Thank you for your work in packaging golang-github-aymerick-douceur! I picked up from where you left off, and uploaded the package, which is now sitting in the NEW queue. golang-github-aymerick-douceur-dev is needed by golang-github-microcosm-cc-bluemonday 1.0.6 and up, which is needed by golang-github-charmbracelet-glamour, which is needed by gh (GitHub CLI). I renamed the golang-github-aymerick-douceur-dev package to simply douceur. Cheers, Anthony -- Forwarded message - From: Debian FTP Masters Date: Thu, Sep 2, 2021 at 6:48 AM Subject: golang-github-aymerick-douceur_0.2.0-1_amd64.changes is NEW To: Debian Go Packaging Team , Anthony Fok binary:douceur is NEW. binary:golang-github-aymerick-douceur-dev is NEW. binary:douceur is NEW. binary:golang-github-aymerick-douceur-dev is NEW. source:golang-github-aymerick-douceur is NEW. Your package has been put into the NEW queue, which requires manual action from the ftpteam to process. The upload was otherwise valid (it had a good OpenPGP signature and file hashes are valid), so please be patient. Packages are routinely processed through to the archive, and do feel free to browse the NEW queue[1]. If there is an issue with the upload, you will receive an email from a member of the ftpteam. If you have any questions, you may reply to this email. [1]: https://ftp-master.debian.org/new.html or https://ftp-master.debian.org/backports-new.html for *-backports
Bug#993652: ITP: golang-github-bep-gowebp -- C bindings and an API for encoding WebP images (Go library)
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-bep-gowebp Version : 0.1.0-1 Upstream Author : Bjørn Erik Pedersen * URL : https://github.com/bep/gowebp * License : Expat Programming Lang: Go Description : C bindings and an API for encoding WebP images (Go library) This library provides C bindings and an API for *encoding* WebP images using Google's libwebp (https://github.com/webmproject/libwebp) for Go. . It is based on github.com/kolesa-team/go-webp, but this includes and builds the libwebp C source from a versioned Git subtree. . Compiling C code isn't particulary fast; if you install libwebp-dev, you can link against that instead by adding the "dev" tag: . $ apt install libwebp-dev $ go test ./libwebp -tags dev Reason for packaging: Prerequisite for hugo (>= 0.83.0)
Bug#993442: ITP: golang-github-charmbracelet-glamour -- stylesheet-based Markdown rendering for your CLI apps
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-charmbracelet-glamour Version : 0.3.0-1 Upstream Author : Charmbracelet, Inc. * URL : https://github.com/charmbracelet/glamour * License : Expat Programming Lang: Go Description : stylesheet-based Markdown rendering for your CLI apps (Go library) glamour lets you render Markdown documents and templates on ANSI-compatible terminals. You can create your own stylesheet or simply use one of the stylish defaults. Reason for packaging: golang-github-charmbracelet-glamour-dev is a prerequisite of gh (GitHub CLI)
