Bug#1033839: Packaging docker 24.0.9
Hi Tianon, Actually I'm lost with the upstream version policy after they changed the schema. Is there still something called "LTS"? -- Shengjing Zhu
Bug#1068136: Updating golang-github-golang-protobuf-1-5 to fix FTBFS
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 -- Shengjing Zhu
Bug#1069310: FTBFS: tests failed
Control: reassign -1 golang-github-hanwen-go-fuse-dev
Control: affects -1 src:gocryptfs
On Sat, Apr 20, 2024 at 2:54 AM Andrey Rakhmatullin wrote:
>
> Source: gocryptfs
> Version: 2.4.0-1
> Severity: serious
> Tags: ftbfs
>
> https://buildd.debian.org/status/fetch.php?pkg=gocryptfs=mips64el=2.4.0-1%2Bb6=1713405841=0
>
> panic: DIRECT (8000) overlaps with LARGEFILE (8000)
>
> goroutine 1 [running]:
> github.com/hanwen/go-fuse/fuse.(*flagNames).set(0xc000126708, 0x8000,
> {0x1201d640e, 0x6})
>
> /<>/_build/src/github.com/hanwen/go-fuse/fuse/print.go:126
> +0x234
> github.com/hanwen/go-fuse/fuse.init.1()
> /<>/_build/src/github.com/hanwen/go-
> fuse/fuse/print_linux.go:13 +0x68
> FAILgithub.com/rfjakob/gocryptfs/internal/syscallcompat 0.007s
>
This is similar to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061659 and
https://github.com/hanwen/go-fuse/issues/502 which is only fixed on
i386.
--
Shengjing Zhu
Bug#1063077: syslog-ng: identified for time_t transition but no ABI in shlibs
On Mon, Apr 8, 2024 at 9:15 PM Attila Szalay wrote:
>
> Ok. I re-checked the patch and realized that I checked the only wrong
> module (the only one which is arch all and not any).
>
> So my apologies for the fuzz and will apply the patch with the
> appropriate changes.
>
> But here my original reply too:
>
> I admit that I joined late to this conversation. But my complain is not
> about the time_t change.
>
> My complain is the contradiction between two thing:
> 1. https://wiki.debian.org/binNMU says that I should declar[e]
> dependency between an arch: all to an arch: any package: Depends: foo
> (>= ${source:Version}), foo (<< ${source:Version}.1~)
>
This is for arch: all -> arch: any. However I see most syslog-ng-mod-*
packages are arch: any. So it should just use strict equal on
syslog-ng-core.
What I'm confused about is some syslog-ng-mod-* packages are arch:
all, which don't have .so in it. Then why do they need to depend on
syslog-ng-core?
> 2. The bug report ask to depend on 'syslog-ng-core (=
> $${binary:Version})'
>
> This two is contradict and because syslog-ng complies with the binNMU
> request, I really reluctant to change that. Especially because in that
> case another ticket will be created in no-time to revert it.
>
> This is from the proposed changelog:
> + * Adjust shlibs for syslog-ng-core to use a strict versioned depends;
> +previously, modules used >=, << dependencies which did not account for
> +the possibility of ABI skew in a binNMU, which is exactly what happens
> +with the 64-bit time_t transition.
>
> And my question is again, is the rules really changed or we bend the
> rules just because of one transition?
--
Shengjing Zhu
Bug#1068056: ccls: FTBFS on armhf,i386 (test_response failures)
Control: severity -1 wishlist Control: forcemerge 1068055 -1 On Sat, Mar 30, 2024 at 2:57 PM Kentaro HAYASHI wrote: > > Source: ccls > Severity: serious > Tags: ftbfs > Control: found -1 0.20230717-1 > X-Debbugs-Cc: ken...@xdump.org > > Dear Maintainer, > > ccls fails to build on armhf, i386. > As explained in 1068055. -- Shengjing Zhu
Bug#1068055: ccls: FTBFS on armel (undefined reference to symbol '__atomic_load_8@@LIBATOMIC_1.0')
Control: severity -1 wishlist On Sat, Mar 30, 2024 at 3:00 PM Kentaro HAYASHI wrote: > > Source: ccls > Severity: serious > Tags: ftbfs > Control: found -1 2.6.0-1 > X-Debbugs-Cc: ken...@xdump.org > > Dear Maintainer, > > ccls fails to build on armel. (missing linking against with -latomic) It's fine, as it never successfully built before. Even if it builds, the test will fail. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934408 -- Shengjing Zhu
Bug#1067390: ITP: watcher -- watch for files or directory changes without using filesystem events
On Thu, Mar 21, 2024 at 5:39 AM Arthur Diniz wrote: > > Package: wnpp > Severity: wishlist > Owner: Arthur Diniz > > * Package name: watcher There is already a package named watcher https://tracker.debian.org/pkg/watcher. Maybe you can use go-watcher or golang-watcher for the package name. But the cli /usr/bin/watcher is already taken by python3-watcherclient. -- Shengjing Zhu
Bug#1066778: golang-github-containerd-go-runc: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 8 github.com/containerd/go-runc returned exit code 1
On Wed, Mar 13, 2024 at 11:05 PM Lucas Nussbaum wrote: > > Source: golang-github-containerd-go-runc > Version: 1.0.0-1 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240313 ftbfs-trixie > [...] > > console_test.go:42: mkdir /tmp/foo: not a directory > > --- FAIL: TestTempConsoleWithXdgRuntimeDir (0.00s) I wonder if your chroot doesn't have the /tmp directory? -- Shengjing Zhu
Bug#1055439: RM: golang-github-docker-go-plugins-helpers [all] -- RoQA; NBS; renamed to golang-github-docker-go-plugins-helpers-dev
On Mon, Nov 06, 2023 at 04:47:22AM +0100, Andreas Beckmann wrote: > Package: ftp.debian.org > Severity: normal > > The badly named arch:all binary package has been renamed. This has been removed. = [Date: Fri, 15 Dec 2023 18:27:47 -] [ftpmaster: Thorsten Alteholz] Removed the following packages from unstable: golang-github-docker-go-plugins-helpers | 0.20211224-1 | all --- Reason --- [auto-cruft] NBS (no longer built by golang-github-docker-go-plugins-helpers - based on source metadata) -- =
Bug#1064954: RM: golang-1.20 -- ROM; EOL; superseded by golang-1.21 & golang-1.22
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: golang-1...@packages.debian.org, z...@debian.org Control: affects -1 + src:golang-1.20 User: ftp.debian@packages.debian.org Usertags: remove With the release of golang-1.22, golang-1.20 is EOL now.
Bug#1064825: RM: golang-github-appc-spec -- RoQA; upstream discontinued 4 years ago
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: golang-github-appc-s...@packages.debian.org, z...@debian.org Control: affects -1 + src:golang-github-appc-spec User: ftp.debian@packages.debian.org Usertags: remove This package is forgotten to be removed when rkt and its related packages got removed from archive.
Bug#1064498: autopkgtest fails with golang-1.22
Source: ycmd Version: 0+20231230+git9e43034+ds-1 Severity: important X-Debbugs-Cc: z...@debian.org Control: fowarded -1 https://github.com/ycm-core/ycmd/commit/492a771df3c3248185e8fe3a82392efe8773250e Hi, I'm going to change golang-defaults to Go 1.22, and your package's test fails to run. It has been fixed by upstream, could you please backport the following commit. See https://github.com/ycm-core/ycmd/commit/492a771df3c3248185e8fe3a82392efe8773250e
Bug#1061659: Fwd: Bug#1061659: src:golang-github-hanwen-go-fuse: fails to migrate to testing for too long: i386 autopkgtest regression
Control: forwarded -1 https://github.com/hanwen/go-fuse/issues/502 On Mon, Jan 29, 2024 at 1:42 AM Julian Gilbey wrote: > > Hi Nilesh, > > You did the last upload of this package - do you have any idea about > this bug? > See https://github.com/hanwen/go-fuse/issues/502 -- Shengjing Zhu
Bug#1060839: ITP: golang-github-adamkorcz-go-fuzz-headers-1 -- helper functions for Go fuzzing (library)
On Tue, Jan 16, 2024 at 4:28 AM Simon Josefsson wrote: > > Shengjing Zhu writes: > > > On Mon, Jan 15, 2024 at 8:51 PM Simon Josefsson wrote: > >> > >> Package: wnpp > >> Severity: wishlist > >> Owner: Simon Josefsson > >> > >> * Package name: golang-github-adamkorcz-go-fuzz-headers-1 > >> Version : 0.0~git20230919.8b5d3ce-1 > >> Upstream Author : Adam Korcz > >> * URL : https://github.com/AdamKorcz/go-fuzz-headers-1 > >> * License : Apache-2.0 > >> Programming Lang: Go > >> Description : helper functions for Go fuzzing (library) > >> > >> Various helper functions for go fuzzing. It is mostly used in combination > >> with go-fuzz (https://github.com/dvyukov/go-fuzz), but compatibility with > >> fuzzing in the standard library will also be supported. Any coverage > >> guided > >> fuzzing engine that provides an array or slice of bytes can be used with > >> go-fuzz-headers. > >> . > >> go-fuzz-headers' approach to fuzzing structs is strongly inspired by > >> gofuzz (https://github.com/google/gofuzz). > >> > >> I hope to maintain this package as part of Debian Go Packaging Team: > >> > >> https://salsa.debian.org/go-team/packages/golang-github-adamkorcz-go-fuzz-headers-1/ > >> > > > > Usually we don't run fuzz test when building packages, because it > > would waste a lot of buildd resource. > > > > In theory we don't need any fuzz related libraries. But upstream may > > mix their unit tests and fuzz tests in one source file, which makes it > > difficult to strip such tests and their libraries. > > The Go compiler by default wouldn't run fuzz tests. > > > > For packaging rekor, I think all these fuzz tests can be stripped by > > file names. It seems upstream just puts all fuzz tests in > > "fuzz_test.go". > > What is the best method to modify rekor to not need this dependency? > > If rekor can work without this package, I'm happy to avoid packaging it, > although it is already in NEW. > > Looking at code, it seems to be used here: > > go.sum:github.com/AdamKorcz/go-fuzz-headers-1 > v0.0.0-20230618160516-e936619f9f18 > h1:rd389Q26LMy03gG4anandGFC2LW/xvjga5GezeeaxQk= > go.sum:github.com/AdamKorcz/go-fuzz-headers-1 > v0.0.0-20230618160516-e936619f9f18/go.mod > h1:fgJuSBrJP5qZtKqaMJE0hmhS2tmRH+44IkfZvjtaf1M= > hack/tools/go.sum:github.com/AdamKorcz/go-fuzz-headers-1 > v0.0.0-2023032938-12e09aba5ebd > h1:1tbEqR4NyQLgiod7vLXSswHteGetAVZrMGCqrJxLKRs= > hack/tools/go.sum:github.com/AdamKorcz/go-fuzz-headers-1 > v0.0.0-2023032938-12e09aba5ebd/go.mod > h1:0vOOKsOMKPThRu9lQMAxcQ8D60f8U+wHXl07SyUw0+U= > hack/tools/tools.go:_ "github.com/AdamKorcz/go-fuzz-headers-1" > hack/tools/go.mod: github.com/AdamKorcz/go-fuzz-headers-1 > v0.0.0-2023032938-12e09aba5ebd > pkg/types/hashedrekord/v0.0.1/fuzz_test.go: fuzz > "github.com/AdamKorcz/go-fuzz-headers-1" > pkg/types/rpm/v0.0.1/fuzz_test.go: fuzz > "github.com/AdamKorcz/go-fuzz-headers-1" > pkg/types/alpine/v0.0.1/fuzz_test.go: fuzz > "github.com/AdamKorcz/go-fuzz-headers-1" > pkg/types/alpine/fuzz_test.go: fuzz "github.com/AdamKorcz/go-fuzz-headers-1" > pkg/types/cose/v0.0.1/fuzz_test.go: fuzz > "github.com/AdamKorcz/go-fuzz-headers-1" > pkg/types/jar/v0.0.1/fuzz_test.go: fuzz > "github.com/AdamKorcz/go-fuzz-headers-1" > pkg/types/rekord/v0.0.1/fuzz_test.go: fuzz > "github.com/AdamKorcz/go-fuzz-headers-1" > pkg/types/intoto/v0.0.1/fuzz_test.go: fuzz > "github.com/AdamKorcz/go-fuzz-headers-1" > pkg/types/intoto/v0.0.2/fuzz_test.go: fuzz > "github.com/AdamKorcz/go-fuzz-headers-1" > pkg/types/tuf/v0.0.1/fuzz_test.go: fuzz > "github.com/AdamKorcz/go-fuzz-headers-1" > pkg/types/helm/v0.0.1/fuzz_test.go: fuzz > "github.com/AdamKorcz/go-fuzz-headers-1" > pkg/types/dsse/v0.0.1/fuzz_test.go: fuzz > "github.com/AdamKorcz/go-fuzz-headers-1" > pkg/types/rfc3161/v0.0.1/fuzz_test.go: fuzz > "github.com/AdamKorcz/go-fuzz-headers-1" > pkg/fuzz/alpine_utils.go: fuzz "github.com/AdamKorcz/go-fuzz-headers-1" > pkg/fuzz/fuzz_utils.go: fuzz "github.com/AdamKorcz/go-fuzz-headers-1" > pkg/fuzz/jar_utils.go: fuzz "github.com/AdamKorcz/go-fuzz-headers-1" > go.mod: github.com/AdamKorcz/go-fuzz-headers-1 > v0.0.0-20230618160516-e936619f9f18 > > Would we have to patch all of these files? Or disable building them > somehow? > Just remove these files, either via Files-Excluded in debian/copyright, or rm in builddir in debian/rules. > Let's see if we can develop a workaround before ftp-master approves the > packages... otherwise maybe it doesn't hurt to use it anyway, and may > save us time maintaining patches. > > /Simon -- Shengjing Zhu
Bug#1060839: ITP: golang-github-adamkorcz-go-fuzz-headers-1 -- helper functions for Go fuzzing (library)
On Mon, Jan 15, 2024 at 8:51 PM Simon Josefsson wrote: > > Package: wnpp > Severity: wishlist > Owner: Simon Josefsson > > * Package name: golang-github-adamkorcz-go-fuzz-headers-1 > Version : 0.0~git20230919.8b5d3ce-1 > Upstream Author : Adam Korcz > * URL : https://github.com/AdamKorcz/go-fuzz-headers-1 > * License : Apache-2.0 > Programming Lang: Go > Description : helper functions for Go fuzzing (library) > > Various helper functions for go fuzzing. It is mostly used in combination > with go-fuzz (https://github.com/dvyukov/go-fuzz), but compatibility with > fuzzing in the standard library will also be supported. Any coverage guided > fuzzing engine that provides an array or slice of bytes can be used with > go-fuzz-headers. > . > go-fuzz-headers' approach to fuzzing structs is strongly inspired by > gofuzz (https://github.com/google/gofuzz). > > I hope to maintain this package as part of Debian Go Packaging Team: > > https://salsa.debian.org/go-team/packages/golang-github-adamkorcz-go-fuzz-headers-1/ > Usually we don't run fuzz test when building packages, because it would waste a lot of buildd resource. In theory we don't need any fuzz related libraries. But upstream may mix their unit tests and fuzz tests in one source file, which makes it difficult to strip such tests and their libraries. The Go compiler by default wouldn't run fuzz tests. For packaging rekor, I think all these fuzz tests can be stripped by file names. It seems upstream just puts all fuzz tests in "fuzz_test.go". -- Shengjing Zhu
Bug#1060840: ITP: golang-k8s-sigs-release-utils -- utilities for kubernetes Go release engineering (library)
On Mon, Jan 15, 2024 at 10:25 PM Simon Josefsson wrote: > > Shengjing Zhu writes: > > > On Mon, Jan 15, 2024 at 9:27 PM Simon Josefsson wrote: > >> > >> Package: wnpp > >> Severity: wishlist > >> Owner: Simon Josefsson > >> > >> * Package name: golang-k8s-sigs-release-utils > >> Version : 0.7.7-1 > >> Upstream Author : Kubernetes SIGs > >> * URL : https://github.com/kubernetes-sigs/release-utils > >> * License : Apache-2.0 > >> Programming Lang: Go > >> Description : utilities for kubernetes Go release engineering > >> (library) > >> > >> Tiny utilities for use by the Release Engineering subproject and > >> kubernetes/release (https://github.com/kubernetes/release/). > >> > > > > Which package will need this library? It looks strange by the name and > > description. We certainly don't do the release stuff for kubernetes. > > Sigstore's rekor complained: > > https://salsa.debian.org/jas/golang-github-sigstore-rekor/-/jobs/5160982 > > src/github.com/sigstore/rekor/cmd/backfill-redis/main.go:44:2: cannot find > package "sigs.k8s.io/release-utils/version" in any of: > /usr/lib/go-1.21/src/sigs.k8s.io/release-utils/version (from $GOROOT) > > /builds/jas/golang-github-sigstore-rekor/debian/output/source_dir/_build/src/sigs.k8s.io/release-utils/version > (from $GOPATH) > > Use is here: > > https://github.com/sigstore/rekor/blob/main/cmd/backfill-redis/main.go#L44 > Hmm, then this library is needed. However I just checked the code in sigs.k8s.io/release-utils/version, I'm afraid it's not compatible with how we build Go binaries in Debian. We don't have any VCS info when building the binaries. And we use GOPATH mde as well. So the Go compiler can't inject any version info in the binaries. This code https://github.com/sigstore/rekor/blob/main/cmd/backfill-redis/main.go#L103 would probably just print "unknown, unknown"... > Can you think of some other solution than packaging > golang-k8s-sigs-release-utils? I would be happy to learn about > alternative approaches to reduce golang dependencies. > > /Simon -- Shengjing Zhu
Bug#1060840: ITP: golang-k8s-sigs-release-utils -- utilities for kubernetes Go release engineering (library)
On Mon, Jan 15, 2024 at 9:27 PM Simon Josefsson wrote: > > Package: wnpp > Severity: wishlist > Owner: Simon Josefsson > > * Package name: golang-k8s-sigs-release-utils > Version : 0.7.7-1 > Upstream Author : Kubernetes SIGs > * URL : https://github.com/kubernetes-sigs/release-utils > * License : Apache-2.0 > Programming Lang: Go > Description : utilities for kubernetes Go release engineering (library) > > Tiny utilities for use by the Release Engineering subproject and > kubernetes/release (https://github.com/kubernetes/release/). > Which package will need this library? It looks strange by the name and description. We certainly don't do the release stuff for kubernetes. -- Shengjing Zhu
Bug#1055087: golang-1.21: Add support for loong64
On Tue, Oct 31, 2023 at 4:39 PM chenguoqi wrote: > > Package: golang-1.21 > Version: 1.21.3 > Severity: wishlist > Tags: patch > User: debian-loonga...@lists.debian.org > Usertags: loong64 > > Hi, > > Golang upstream supports loong64 starting from Go1.19 version, and currently > > all dependencies for building golang-1.21 package on debian sid have been > > met. Golang-1.21 on loong64 can now be built. > Could you look at the failures when bootstrapping Go 1.22? https://buildd.debian.org/status/fetch.php?pkg=golang-1.22=loong64=1.22%7Erc1-2=170456=0 -- Shengjing Zhu
Bug#1059860: ITP: golang-github-quic-go-quic-go -- A QUIC implementation in pure go
On Wed, Jan 3, 2024 at 6:14 PM Félix Sipma wrote: > > On 2024-01-02 22:32+0800, Shengjing Zhu wrote: > >On Tue, Jan 2, 2024 at 10:27 PM Félix Sipma wrote: > >> > >> Package: wnpp > >> Severity: wishlist > >> Owner: Félix Sipma > >> > >> * Package name: golang-github-quic-go-quic-go > >> Version : 0.40.0-1 > >> Upstream Author : > >> * URL : https://github.com/quic-go/quic-go > >> * License : Expat > >> Programming Lang: Go > >> Description : A QUIC implementation in pure go > >> > >> A QUIC implementation in pure Go > > > >It's https://tracker.debian.org/pkg/golang-github-lucas-clemente-quic-go > >It has been updated to use the new source. Though it should be better > >to rename the Debian package when upstream moved their code location. > >But I was too lazy to go through NEW when I updated the package. > > Sorry, I did not find golang-github-quic-go-quic-go with "apt search" or > wnpp-check, so I assumed it was not in Debian yet. > Although golang-github-lucas-clemente-quic-go-dev Provides golang-github-quic-go-quic-go-dev, it's hard to search. I found that `apt-cache search` can return the result, but `apt search` does not. OTOH `dh-make-golang search` is the tool to search with Go import path. > Upgrading to >= 0.39 seems implies to deal with incompatibles changes in > the API (and upstream switched to uber's gomock...), but 0.38.2 seems to > be enough to update Syncthing, and should be OK for the other > dependencies. Could you have a look to the upgrade-to-0.38.2 branch of > golang-github-lucas-clemente-quic-go on salsa? > I added one more change to use ginkgo-v2, which is packaged now, and uploaded. -- Shengjing Zhu
Bug#1059860: ITP: golang-github-quic-go-quic-go -- A QUIC implementation in pure go
On Tue, Jan 2, 2024 at 10:27 PM Félix Sipma wrote: > > Package: wnpp > Severity: wishlist > Owner: Félix Sipma > > * Package name: golang-github-quic-go-quic-go > Version : 0.40.0-1 > Upstream Author : > * URL : https://github.com/quic-go/quic-go > * License : Expat > Programming Lang: Go > Description : A QUIC implementation in pure go > > A QUIC implementation in pure Go > It's https://tracker.debian.org/pkg/golang-github-lucas-clemente-quic-go It has been updated to use the new source. Though it should be better to rename the Debian package when upstream moved their code location. But I was too lazy to go through NEW when I updated the package. -- Shengjing Zhu
Bug#1058795: installing docker.io makes all qemu guests lose internet connection
On Tue, Dec 26, 2023 at 5:48 AM Michael Tokarev wrote: > > On Sat, 16 Dec 2023 14:54:32 +0100 Wolfgang Rohdewald > wrote: > > Package: docker.io > > Version: 20.10.24+dfsg1-1+b3 > > Severity: critical > > Justification: breaks unrelated software > > > > Dear Maintainer, > > > >* What led up to the situation? > > > > installed docker.io with existing qemu guests in bridge mode, did not do > > anything else. > > This seems to be because docker includes some firewall rules which does not > play nice with existing firewall rules. For example, in my case I use > nftables, and after docker.io is installed, I had to > Does the suggestion on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865975 help? TLDR, please enable net.ipv4.ip_forward before starting docker. -- Shengjing Zhu
Bug#1056223: abydos autopkg tests fail with Python 3.12
X-Debbugs-CC: j...@debian.org Control: tags -1 patch On Sun, Nov 19, 2023 at 11:39:31AM +0100, Matthias Klose wrote: > Package: src:abydos > Version: 0.5.0+git20201231.344346a-6 > Severity: important > Tags: sid trixie > User: debian-pyt...@lists.debian.org > Usertags: python3.12 > > abydos autopkg tests fail with Python 3.12: > > [...] > 486s == > 486s FAIL: test_mean_pairwise_similarity > (tests.stats.test_stats_pairwise.MPSTestCases.test_mean_pairwise_similarity) > 486s Test abydos.stats.mean_pairwise_similarity. > 486s -- > 486s Traceback (most recent call last): > 486s File > "/tmp/autopkgtest.U4aAdq/autopkgtest_tmp/tests/stats/test_stats_pairwise.py", > line 78, in test_mean_pairwise_similarity > 486s self.assertEqual(mean_pairwise_similarity(NIALL), > 0.29362587170180671) > 486s AssertionError: 0.29362587170180665 != 0.2936258717018067 > 486s > 486s -- > 486s Ran 940 tests in 6.315s > 486s > 486s FAILED (failures=1, skipped=4) > 486s autopkgtest [20:36:15]: test pytest: ---] > 486s pytest FAIL non-zero exit status 1 More tests need to use assertAlmostEqual to compare floating numbers. Please see the merge request https://salsa.debian.org/python-team/packages/abydos/-/merge_requests/1 Thanks
Bug#1057043: RFS: goauthing/2.2.1-1 [ITP] -- CLI authentication utility for srun4000 systems
On Tue, Nov 28, 2023 at 11:27 PM 陈 晟祺 wrote: > > Package: sponsorship-requests > Severity: wishlist > X-Debbugs-CC: debian...@lists.debian.org > > Dear mentors, > > I am looking for a sponsor for my package "goauthing": > > * Package name : goauthing > Version : 2.2.1-1 > Upstream contact : Yuxiang Zhang > * URL : https://github.com/z4yx/GoAuthing > * License : GPL-3.0 > * Vcs : https://salsa.debian.org/go-team/packages/goauthing > Section : golang > > The source builds the following binary packages: > > goauthing - CLI authentication utility for srun4000 systems > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/goauthing/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/g/goauthing/goauthing_2.2.1-1.dsc > > Changes for the initial release: > > goauthing (2.2.1-1) UNRELEASED; urgency=medium > . > * Initial release (Closes: #1057029) > The name goauthing is too generic. The cli name is auth-thu, could the package name be renamed to auth-thu as well? -- Shengjing Zhu
Bug#1056390: FTBFS with fmtlib 10
Source: gerbera
Version: 1.12.1+dfsg-1
Severity: important
Tags: ftbfs
X-Debbugs-Cc: z...@debian.org
Control: forwarded -1 https://github.com/gerbera/gerbera/pull/2840
Control: affects -1 src:fmtlib
I plan to start fmtlib 10 transition soon, your package FTBFS with it.
[ 13%] Building CXX object
CMakeFiles/libgerbera.dir/src/config/setup/config_setup_dictionary.cc.o
/usr/bin/c++ -DATRAILERS -DFMT_SHARED -DGERBERA_VERSION=\"1.12.1\" -DGRBDEBUG
-DHAVE_AVSTREAM_CODECPAR -DHAVE_CURL -DHAVE_EXIV2 -DHAVE_FFMPEG
-DHAVE_FFMPEGTHUMBNAILER -DHAVE_INOTIFY -DHAVE_
JS -DHAVE_LIBEXIF -DHAVE_MAGIC -DHAVE_MATROSKA -DHAVE_MYSQL -DHAVE_NL_LANGINFO
-DHAVE_SETLOCALE -DHAVE_TAGLIB -DONLINE_SERVICES
-DSPDLOG_ACTIVE_LEVEL=SPDLOG_LEVEL_TRACE -DSPDLOG_COMPILED_LI
B -DSPDLOG_FMT_EXTERNAL -DSPDLOG_SHARED_LIB -DTOMBDEBUG -I/<>/src
-I/usr/include/mysql -I/usr/include/libexif -I/usr/include/ebml
-I/usr/include/matroska -isystem /usr/include/
uuid -isystem /usr/include/upnp -isystem /usr/include/taglib -g -O2
-ffile-prefix-map=/<>=. -fstack-protector-strong
-fstack-clash-protection -Wformat -Werror=format-security -
fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++17 -Wall -MD -MT
CMakeFiles/libgerbera.dir/src/config/setup/config_setup_dictionary.cc.o -MF
CMakeFiles/libgerbera.dir/src/config/setu
p/config_setup_dictionary.cc.o.d -o
CMakeFiles/libgerbera.dir/src/config/setup/config_setup_dictionary.cc.o -c
/<>/src/config/setup/config_setup_dictionary.cc
In file included from /usr/include/fmt/format.h:49,
from /<>/src/util/logger.h:38,
from /<>/src/common.h:37,
from /<>/src/config/config_setup.h:33,
from
/<>/src/config/setup/config_setup_client.cc:25:
/usr/include/fmt/core.h: In instantiation of ‘constexpr
fmt::v10::detail::value fmt::v10::detail::make_arg(T&) [with bool
PACKED = true; Context = fmt::v10::basic_format_context; T = const pugi::xml_node; typename
std::enable_if::type = 0]’:
/usr/include/fmt/core.h:1808:51: required from ‘constexpr
fmt::v10::format_arg_store::format_arg_store(T& ...) [with T =
{const char*, const pugi::xml_node}; Context = fmt:
:v10::basic_format_context; Args = {const char*,
pugi::xml_node}]’
/usr/include/fmt/core.h:1826:18: required from ‘constexpr
fmt::v10::format_arg_store::type>::type ...> fmt::v10::make_fo
rmat_args(T& ...) [with Context = basic_format_context; T =
{const char*, const pugi::xml_node}]’
/usr/include/fmt/core.h:2788:44: required from ‘std::string
fmt::v10::format(format_string, T&& ...) [with T = {const char*&, const
pugi::xml_node&}; std::string = std::__cxx11::ba
sic_string; format_string = basic_format_string]’
/<>/src/config/setup/config_setup_client.cc:186:9: required from
here
/usr/include/fmt/core.h:1576:63: error:
‘fmt::v10::detail::type_is_unformattable_for _’ has
incomplete type
1576 | type_is_unformattable_for _;
| ^
/usr/include/fmt/core.h:1580:7: error: static assertion failed: Cannot format
an argument. To make type T formattable provide a formatter specialization:
https://fmt.dev/latest/api.html#udt
1580 | formattable,
| ^~~
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing'), (100, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.5.0-4-amd64 (SMP w/16 CPU threads; PREEMPT)
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
Bug#1056389: FTBFS with fmtlib 10
Source: termpaint
Version: 0.3.0-3
Severity: important
Tags: ftbfs
X-Debbugs-Cc: z...@debian.org
Control: affects -1 src:fmtlib
I plan to start fmtlib 10 transition soon, your package FTBFS with it.
[14/51] c++ -Imcheck.p -I. -I.. -I/usr/include/docopt
-fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
-std=c++14 -fvisibility=hidden -fvisibility-inlines-hidden -DTERM
PAINT_EXPORT_SYMBOLS -Wall -Wextra -Werror=return-type -g -O2
-ffile-prefix-map=/<>=. -fstack-protector-strong
-fstack-clash-protection -Wformat -Werror=format-security -fcf-pr
otection -Wdate-time -D_FORTIFY_SOURCE=2 -MD -MQ mcheck.p/tools_mcheck.cpp.o
-MF mcheck.p/tools_mcheck.cpp.o.d -o mcheck.p/tools_mcheck.cpp.o -c
../tools/mcheck.cpp
FAILED: mcheck.p/tools_mcheck.cpp.o
c++ -Imcheck.p -I. -I.. -I/usr/include/docopt -fdiagnostics-color=always
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c++14 -fvisibility=hidden
-fvisibility-inlines-hidden -DTERMPAINT_EX
PORT_SYMBOLS -Wall -Wextra -Werror=return-type -g -O2
-ffile-prefix-map=/<>=. -fstack-protector-strong
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
-Wdate-time -D_FORTIFY_SOURCE=2 -MD -MQ mcheck.p/tools_mcheck.cpp.o -MF
mcheck.p/tools_mcheck.cpp.o.d -o mcheck.p/tools_mcheck.cpp.o -c
../tools/mcheck.cpp
In file included from /usr/include/fmt/format.h:49,
from ../tools/mcheck.cpp:22:
/usr/include/fmt/core.h: In instantiation of ‘constexpr
fmt::v10::detail::value fmt::v10::detail::make_arg(T&) [with bool
PACKED = true; Context = fmt::v10::basic_format_context; T = update_interpretation(std::string)::; typename std::enable_if::type = 0]’:
/usr/include/fmt/core.h:1808:51: required from ‘constexpr
fmt::v10::format_arg_store::format_arg_store(T& ...) [with T =
{std::__cxx11::basic_string, std::allocator >, update_interpretation(std::string)::}; Context = fmt::v10::basic_format_context;
Args = {std::__cxx11::basic_string, std::allocator >,
update_interpretation(std::string)::}]’
/usr/include/fmt/core.h:1826:18: required from ‘constexpr
fmt::v10::format_arg_store::type>::type ...> fmt::v10::make_fo
rmat_args(T& ...) [with Context = basic_format_context; T =
{std::__cxx11::basic_string, std::allocator
>, update_interpretation(std::stri
ng)::}]’
/usr/include/fmt/core.h:2788:44: required from ‘std::string
fmt::v10::format(format_string, T&& ...) [with T =
{std::__cxx11::basic_string, std::alloca
tor >&, update_interpretation(std::string)::&}; std::string
= std::__cxx11::basic_string; format_string =
basic_format_string, std::allocator >&,
update_interpretation(std::string)::&>]’
../tools/mcheck.cpp:172:32: required from here
/usr/include/fmt/core.h:1580:7: error: static assertion failed: Cannot format
an argument. To make type T formattable provide a formatter specialization:
https://fmt.dev/latest/api.html#udt
1580 | formattable,
| ^~~
/usr/include/fmt/core.h:1580:7: note: ‘formattable’ evaluates to false
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing'), (100, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.5.0-4-amd64 (SMP w/16 CPU threads; PREEMPT)
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
Bug#1056388: FTBFS with fmtlib 10
Source: pytorch Version: 2.0.1+dfsg-5 Severity: important Tags: ftbfs X-Debbugs-Cc: z...@debian.org Control: forwarded -1 https://github.com/pytorch/pytorch/pull/106672 Control: affects -1 src:fmtlib I plan to start fmtlib 10 transition soon, your package FTBFS with it. /<>/torch/csrc/distributed/rpc/agent_utils.cpp:160:18: required from here /usr/include/fmt/core.h:1576:63: error: ‘fmt::v10::detail::type_is_unformattable_for, char> _’ has incomplete type 1576 | type_is_unformattable_for _; | ^ /usr/include/fmt/core.h:1580:7: error: static assertion failed: Cannot format an argument. To make type T formattable provide a formatter specialization: https://fmt.dev/latest/api.html#udt 1580 | formattable, | ^~~ -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-4-amd64 (SMP w/16 CPU threads; PREEMPT) 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
Bug#1056387: FTBFS with fmtlib 10
Source: mariadb Version: 1:10.11.5-3 Severity: important X-Debbugs-Cc: z...@debian.org Control: forwarded -1 https://github.com/MariaDB/server/pull/2732 Control: affects -1 src:fmtlib I plan to start fmtlib 10 transition soon, your package FTBFS with it. Please see upstream report and fix. https://jira.mariadb.org/browse/MDEV-31963 https://github.com/MariaDB/server/pull/2732 -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-4-amd64 (SMP w/16 CPU threads; PREEMPT) 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
Bug#1055700: netdev in official Debian cloud image has GID=1000
On Fri, Nov 10, 2023 at 4:57 PM Osamu Aoki wrote: > > Source: lxd > Version: 5.0.2-5 > Severity: minor > > `lxc launch` generated Debian cloud image (bookworm) has odd /etc/group > in it. GID=1000 is netdev. If it is properly generated using > --- > # addgroup --system netdev > --- > this GID for netdev should be somewhare between 100 and 999. > > Although, I know that this is most likely not caused by the lxd source, > I didn't know where to file this bug. Please reassign this report to > appropriate resources. > Which image are you using? If the image is from https://images.linuxcontainers.org (eg using the images: remote), then you can report it at https://github.com/lxc/distrobuilder. If you download the image from https://cloud.debian.org/images/ and import it to lxd, then you can report it against the cloud.debian.org pseudo package. -- Shengjing Zhu
Bug#1050216: cpu-features: FTBFS on armhf, armel "Including cpuinfo_aarch64.h from a non-aarch64 target"
On Tue, Aug 22, 2023 at 5:45 PM Emanuele Rocca wrote: > > Hi! > > On 2023-08-22 04:42, Shengjing Zhu wrote: > > I can't reproduce it on abel.debian.org > > https://db.debian.org/machines.cgi?host=abel > > I assume you are cross building, or running it on an armhf/armel > > container on arm64 host. > > Ah yes, good catch, I'm building on a arm64 host with: > > sbuild --arch=armhf > > Note that building 0.7.0-1 with `Machine Architecture: arm64` worked in > the past, see: > https://buildd.debian.org/status/fetch.php?pkg=cpu-features=armhf=0.7.0-1=1655403767=0 I uploaded 0.9.0-1, and it still builds on buildd for armhf/armel, with `Machine Architecture: arm64`. Could you test again? or maybe you have a different setup then buildd? -- Shengjing Zhu
Bug#1055441: ITP: golang-golang-x-telemetry -- Go Telemetry services and libraries
On Mon, Nov 6, 2023 at 3:33 PM Anthony Fok wrote: > > 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) > IMO Debian has tradition to disable upstream telemetry features, so it's disabled gopls currently, not just because this new dependency is not packaged. -- Shengjing Zhu
Bug#1053799: golang-github-libgit2-git2go: no upstream support for latest libgit2
On Sun, Nov 5, 2023 at 4:45 AM Timo Röhling wrote: > > Hi Mohammed, Pirate, > > On Wed, 11 Oct 2023 15:39:42 +0200 =?utf-8?q?Timo_R=C3=B6hling?= > wrote: > > Source: golang-github-libgit2-git2go > > Version: 34.0.0-4 > > Severity: important > > Tags: upstream > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > Dear maintainer, > > > > the Go bindings for libgit2 are out of date with respect to libgit2, > > which blocks the planned transition of libgit2 1.7. > > > > I think the Go bindings either need to be updated to work with libgit > > 1.7 or removed from Debian for lack of upstream support. > > > Can you comment on this? > git2go is packaged for building gitaly. gitaly upstream has dropped the git2go dependency. Ref: https://gitlab.com/groups/gitlab-org/-/epics/9092 So IMO you can start libgit2 transition, and bump this bug's severity. -- Shengjing Zhu
Bug#1055134: ITP: golang-github-bits-and-blooms-bloom -- Go package implementing Bloom filters, used by Milvus and Beego.
Hi, On Wed, Nov 1, 2023 at 11:21 AM John Goerzen wrote: > > Package: wnpp > Severity: wishlist > Owner: John Goerzen > > * Package name: golang-github-bits-and-blooms-bloom > Version : 3.6.0-1 > Upstream Author : Will Fitzgerald > * URL : https://github.com/bits-and-blooms/bloom > * License : BSD-2-clause > Programming Lang: Go > Description : Go package implementing Bloom filters, used by Milvus and > Beego. > This package was called golang-github-willf-bloom previously. Upstream just renamed. And golang-github-willf-bloom also adds github.com/bits-and-blooms/bloom as import path. https://tracker.debian.org/pkg/golang-github-willf-bloom -- Shengjing Zhu
Bug#1054504: RM: golang-github-facebook-ent -- RoQA; superseded by golang-entgo-ent
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: golang-github-facebook-...@packages.debian.org, z...@debian.org Control: affects -1 + src:golang-github-facebook-ent This package is superseded by golang-entgo-ent. No reverse depends for golang-github-facebook-ent.
Bug#1032107: Don't release with bookworm
On Tue, Oct 24, 2023 at 9:57 PM Nilesh Patra wrote: > > Hi Shengjing, > > On Tue, 28 Feb 2023 13:43:13 +0800 Shengjing Zhu wrote: > > Source: golang-github-jesseduffield-go-getter > > Version: 0.0~git20180822.906e156-5 > > Severity: serious > > X-Debbugs-Cc: z...@debian.org > > > > > > Fork of golang-github-hashicorp-go-getter. > > No new development in https://github.com/jesseduffield/go-getter since 2018 > > No reverse-depends. > > You had filed a bunch of such bugs before bookworm release. Do you think > it is fine to remove them from the archive? > > If so these BRs could be convered to ROM. > I only file RC bug to prevent these packages migrating to testing, because these packages are related to some upstreams who like to fork libraries. For example, this package is related to https://github.com/jesseduffield who is also the maintainer of lazygit. I don't want to put burden (like going through NEW again) on those who continue the effort to package lazygit. -- Shengjing Zhu
Bug#1053909: anbox: Failed to start as either binder or ashmem kernel drivers are not loaded
On Sat, Oct 14, 2023 at 12:21 PM Alex Relis wrote: > Further research also tells me that Anbox's development is inactive, so > I might just give up on this. Just thought I'd let you know about the > status of this package. anbox is already removed from Debian 12 and later. https://tracker.debian.org/pkg/anbox -- Shengjing Zhu
Bug#1053698: RM: golang-1.19 -- ROM; superseded by golang-1.20 & golang-1.21
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: golang-1...@packages.debian.org, z...@debian.org Control: affects -1 + src:golang-1.19 Please remove golang-1.19.
Bug#1052998: ITP: golang-github-moby-spdystream -- A multiplexed stream library using spdy
On Wed, Sep 27, 2023 at 2:15 AM Arthur Diniz wrote: > > Package: wnpp > Severity: wishlist > Owner: Arthur Diniz > > * Package name: golang-github-moby-spdystream > Version : 0.2.0-1 > Upstream Author : Moby > * URL : https://github.com/moby/spdystream > * License : Apache-2.0 and BSD-3-Clause > Programming Lang: Go > Description : A multiplexed stream library using spdy > Already packaged as golang-github-docker-spdystream. -- Shengjing Zhu
Bug#1042049: lintian: FTBFS: 3 tests failed
Control: tags -1 + patch Hi, Please see the following patch https://salsa.debian.org/lintian/lintian/-/merge_requests/480
Bug#1052219: unrecognized option '--insert-timestamp=1686475264'
On Tue, Sep 19, 2023 at 5:08 PM Andreas Metzler wrote: > > Control: tags 1052219 moreinfo > > On 2023-09-19 Shengjing Zhu wrote: > > On Tue, Sep 19, 2023 at 2:57 PM Shengjing Zhu wrote: > > > Package: binutils-mingw-w64-i686 > > > Version: 2.41-4+11+nmu1 > [...] > >> The NMU binutils-mingw-w64/11+nmu1 drops specify-timestamp.patch. > >> It causes libgcrypt20, gcc-mingw-w64 FTBFS. > >> > >> These packages use options like --insert-timestamp=1686475264, > >> which is not supported in upstream implementation. > >> > >> I find such option is mentioned on > >> https://wiki.debian.org/ReproducibleBuilds/TimestampsInPEBinaries > >> It looks like Debian specific behaviour. > > > Asking libgcrypt20 and gcc-mingw-w64 to stop using this option makes more > > sense. > > > Looking at the changelog entry > * Drop specify-timestamp.patch, applied upstream in binutils 2.41 > (Closes: #1042734) > changing the rdeps does not make any sense at all, since the > --insert-timestamp support is now supposed to be available upstream? > Since binutils-mingw-w64-i686 is reported to be 2.41 the support should > be available. So is binutils-mingw-w64-i686 actually 2.41 and if yes, > why does "applied upstream" not hold? Upstream implements it in a different way, it doesn't take argument in --insert-timestamp option, it just looks SOURCE_DATE_EPOCH implicitly. Ref https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=6badd1020f5bebd3f60a780b8e41a1b581046087 > > Nicholas (as NMUer) - can you explain? > -- Shengjing Zhu
Bug#1052219: unrecognized option '--insert-timestamp=1686475264'
Control: reassign -1 src:libgcrypt20 1.10.2-2 Control: clone -1 -2 Control: reassign -2 src:gcc-mingw-w64 25.2 On Tue, Sep 19, 2023 at 2:57 PM Shengjing Zhu wrote: > > Package: binutils-mingw-w64-i686 > Version: 2.41-4+11+nmu1 > Severity: serious > Tags: ftbfs > X-Debbugs-Cc: ol...@debian.org, z...@debian.org > > The NMU binutils-mingw-w64/11+nmu1 drops specify-timestamp.patch. > It causes libgcrypt20, gcc-mingw-w64 FTBFS. > > These packages use options like --insert-timestamp=1686475264, > which is not supported in upstream implementation. > > I find such option is mentioned on > https://wiki.debian.org/ReproducibleBuilds/TimestampsInPEBinaries > It looks like Debian specific behaviour. Asking libgcrypt20 and gcc-mingw-w64 to stop using this option makes more sense. -- Shengjing Zhu
Bug#1052219: unrecognized option '--insert-timestamp=1686475264'
Package: binutils-mingw-w64-i686 Version: 2.41-4+11+nmu1 Severity: serious Tags: ftbfs X-Debbugs-Cc: ol...@debian.org, z...@debian.org The NMU binutils-mingw-w64/11+nmu1 drops specify-timestamp.patch. It causes libgcrypt20, gcc-mingw-w64 FTBFS. These packages use options like --insert-timestamp=1686475264, which is not supported in upstream implementation. I find such option is mentioned on https://wiki.debian.org/ReproducibleBuilds/TimestampsInPEBinaries It looks like Debian specific behaviour.
Bug#1052175: ITP: golang-github-yuin-goldmark-highlighting-v2 -- A Syntax highlighting extension for the goldmark markdown parser (v2)
On Tue, Sep 19, 2023 at 2:06 AM Peymaneh wrote: > > Package: wnpp > Severity: wishlist > Owner: Peymaneh > > * Package name: golang-github-yuin-goldmark-highlighting-v2 > Version : 0.0~git20230729.37449ab-1 > Upstream Author : Yusuke Inuzuka > * URL : https://github.com/yuin/goldmark-highlighting > * License : Expat > Programming Lang: Go > Description : A Syntax highlighting extension for the goldmark markdown > parser. > > This package provides github.com/yuin/goldmark-highlighting/v2 > > Version 1 is packaged in Debian as golang-github-yuin-goldmark-highlighting > > Version 2 is needed for updating Caddy. > v1 is only used by caddy, you can just update it to v2 without changing source & binary package name when you upload the new version of caddy. There is no rule that major versions must be packaged separately. It's only needed when the transition is hard to coordinate with all the reverse-depends. (Just comparing to the C libraries, we only add version suffix in -dev package name when reverse-depends are hard to adapt to the new api.) -- Shengjing Zhu
Bug#1051980: FTBFS on i386: angle-test/bezier-test fail
Control: tag -1 + patch Hi, On Fri, Sep 15, 2023 at 4:27 PM Shengjing Zhu wrote: > The following tests FAILED: > 2 - angle-test (Failed) > 3 - bezier-test (Failed) They are caused by gcc-13 which defaults to -fexcess-precision=standard for c++. Please see the attached patch. -- Shengjing Zhu lib2geom_1.2.2-3.1.debdiff Description: Binary data
Bug#1034732: marked as done (Keep out of testing)
On Wed, Sep 13, 2023 at 4:04 PM Sebastian Ramacher wrote: > > Control: reopen -1 > > Hi, > > the bug was meant to keep the package out of testing as long as it is > not maintained. Unless you are volunteering to maintain it, this bug is > not fixed. > Yes, it's unfortunately auto-closed by the changelog... -- Shengjing Zhu
Bug#1041504: moc: FTBFS with ffmpeg 6.0
Hi, On Wed, Jul 19, 2023 at 09:48:41PM +0200, Sebastian Ramacher wrote: > Source: moc > Version: 1:2.6.0~svn-r3005-3 > Severity: important > Tags: ftbfs sid trixie > X-Debbugs-Cc: sramac...@debian.org > > moc FTBFS with ffmpeg 6.0 (available in experimental): I NMU 2.6.0~svn-r3005-3.1 which fixes building with ffmpeg 6.0. Please see patch at https://salsa.debian.org/riesebie/moc/-/merge_requests/3
Bug#1043108: libevent: fails to build against glibc 2.38
On Sat, Sep 9, 2023 at 9:21 PM Nicolas Mora wrote: > > Le 2023-09-08 à 02 h 51, Samuel Thibault a écrit : > >>> is the only exposure, and that file is not installed, so there is no way > >>> for another package to produce a reference to it. I did check on the > >>> archive in the amd64 case, no package does. > >>> > >> > >> Thanks, that's indeed not possible to use. > > > > That being said, like #1043184 you will need to make libevent-core-2.1-7 > > Break the previous versions of the other libevent packages, to make sure > > they get upgraded to the version that doesn't use event_strlcpy_ any > > more. > > > > Thanks, therefore adding 'Breaks: libevent-2.1-7 (<= 2.1.12-stable-8)' > in the d/control file will make the other packages rebuild then. > It looks like there is no need for Breaks. $ apt rdepends libevent-core-2.1-7 |grep libevent libevent-core-2.1-7 Depends: libevent-dev (= 2.1.12-stable-8) Depends: libevent-pthreads-2.1-7 (= 2.1.12-stable-8) Depends: libevent-openssl-2.1-7 (= 2.1.12-stable-8) Depends: libevent-extra-2.1-7 (= 2.1.12-stable-8) All these packages have strict equal dependency on libevent-core-2.1-7. -- Shengjing Zhu
Bug#1043108: libevent: fails to build against glibc 2.38
On Fri, Sep 8, 2023 at 1:10 AM Samuel Thibault wrote: > > Shengjing Zhu, le ven. 08 sept. 2023 00:05:23 +0800, a ecrit: > > On Sun, Aug 06, 2023 at 10:30:38AM +0200, Samuel Thibault wrote: > > > Source: libevent > > > Version: 2.1.12-stable-8 > > > Severity: important > > > Tags: patch > > > > > > Hello, > > > > > > libevent fails to build against glibc 2.38: > > > > > > --- debian/libevent-core-2.1-7.symbols.original 2023-08-06 > > > 10:17:18.031636016 +0200 > > > +++ debian/libevent-core-2.1-7.symbols 2023-08-06 10:17:28.135665241 > > > +0200 > > > @@ -310,7 +310,6 @@ > > > event_set_mem_functions@Base 2.1.8-stable > > > event_sock_err@Base 2.1.8-stable > > > event_sock_warn@Base 2.1.8-stable > > > - (arch=!musl-linux-any)event_strlcpy_@Base 2.1.8-stable > > > event_warn@Base 2.1.8-stable > > > event_warnx@Base 2.1.8-stable > > > > I don't understand why it's safe to drop this symbol. > > Because it's not exposed in the API to other packages: > > ./strlcpy-internal.h:#define strlcpy event_strlcpy_ > > is the only exposure, and that file is not installed, so there is no way > for another package to produce a reference to it. I did check on the > archive in the amd64 case, no package does. > Thanks, that's indeed not possible to use. -- Shengjing Zhu
Bug#1043108: libevent: fails to build against glibc 2.38
X-Debbugs-CC: sthiba...@debian.org Hi, On Sun, Aug 06, 2023 at 10:30:38AM +0200, Samuel Thibault wrote: > Source: libevent > Version: 2.1.12-stable-8 > Severity: important > Tags: patch > > Hello, > > libevent fails to build against glibc 2.38: > > --- debian/libevent-core-2.1-7.symbols.original 2023-08-06 > 10:17:18.031636016 +0200 > +++ debian/libevent-core-2.1-7.symbols2023-08-06 10:17:28.135665241 > +0200 > @@ -310,7 +310,6 @@ > event_set_mem_functions@Base 2.1.8-stable > event_sock_err@Base 2.1.8-stable > event_sock_warn@Base 2.1.8-stable > - (arch=!musl-linux-any)event_strlcpy_@Base 2.1.8-stable > event_warn@Base 2.1.8-stable > event_warnx@Base 2.1.8-stable I don't understand why it's safe to drop this symbol. I think the bug is same as https://bugs.debian.org/1023284, which needs workaround to keep the exported symbol with new glibc. -- Shengjing Zhu
Bug#1051333: RM: golang-github-appc-goaci -- RoQA; Upstream discontinued; not useful after removing rkt
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: golang-github-appc-go...@packages.debian.org, z...@debian.org Control: affects -1 + src:golang-github-appc-goaci This library is for rkt, which is discontinued by upstream and removed in Debian.
Bug#1050900: FTBFS: cannot find package "github.com/cheggaaa/pb"
Source: aptly Version: 1.5.0+ds1-1 Severity: serious Tags: ftbfs trixie sid patch X-Debbugs-Cc: z...@debian.org src/github.com/aptly-dev/aptly/console/progress.go:9:2: cannot find package "github.com/cheggaaa/pb" in any of: /usr/lib/go-1.21/src/github.com/cheggaaa/pb (from $GOROOT) /<>/obj-x86_64-linux-gnu/src/github.com/cheggaaa/pb (from $GOPATH) It's because golang-gopkg-cheggaaa-pb.v1-dev remove this compatible symlink which is conflict with golang-github-cheggaaa-pb-dev package. Please see the patch https://salsa.debian.org/debian/aptly/-/merge_requests/11 -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-2-amd64 (SMP w/16 CPU threads; PREEMPT) 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
Bug#1050861: RM: golang-github-twstrike-gotk3adapter -- RoQA; FTBFS since 2021, coyim leaf library
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: golang-github-twstrike-gotk3adap...@packages.debian.org, z...@debian.org Control: affects -1 + src:golang-github-twstrike-gotk3adapter golang-github-twstrike-gotk3adapter was introduced to build coyim, which is already removed in 2021, see #994195.
Bug#1050679: golang-github-twstrike-gotk3adapter: Unnecessary build dependency libgio-cil
On Tue, Aug 29, 2023 at 1:12 AM Bastian Germann wrote: > > Am 28.08.23 um 19:09 schrieb Shengjing Zhu: > > Have you seen that this package is FTBFS > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997717 > > > > I don't think NMU dropping libgio-cil makes sense at this point... > > It does, please see #1049372. Well, the source package of golang-github-twstrike-gotk3adapter/0.0~git20170505.0.901a95d+ds-3.1 is still in unstable if -3.2 is not built... Looks more than a `dak rm` bug if it stops complaining. But ftp-master can remove packages even if `dak rm` complains. /shrug -- Shengjing Zhu
Bug#1050679: golang-github-twstrike-gotk3adapter: Unnecessary build dependency libgio-cil
On Mon, Aug 28, 2023 at 7:00 AM Bastian Germann wrote: > > Source: golang-github-twstrike-gotk3adapter > Severity: minor > Version: 0.0~git20170505.0.901a95d+ds-3.1 > > libgio-cil is a C# library and not even its development package. > There is no reason to have this in a go package so please drop it. > Have you seen that this package is FTBFS https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997717 I don't think NMU dropping libgio-cil makes sense at this point...
Bug#1050168: FTBFS: test_no_local_cert: tlsv13 alert certificate required
Hi,
On Thu, Aug 24, 2023 at 5:38 AM Alberto Bertogli
wrote:
>
> On Mon, Aug 21, 2023 at 05:32:53PM +0800, Shengjing Zhu wrote:
> >Source: kxd
> >Version: 0.15-4
> >Severity: serious
> >Tags: ftbfs
> >X-Debbugs-Cc: albert...@blitiri.com.ar, z...@debian.org
> >
> >I'm not sure if it's related to golang-defaults -> golang-1.21 recently.
> >
> [...]
> >Traceback (most recent call last):
> > File "/<>/tests/run_tests", line 360, in test_no_local_cert
> >self.assertEqual(err.reason, "SSLV3_ALERT_BAD_CERTIFICATE")
> >AssertionError: 'TLSV13_ALERT_CERTIFICATE_REQUIRED' !=
> >'SSLV3_ALERT_BAD_CERTIFICATE'
> >- TLSV13_ALERT_CERTIFICATE_REQUIRED
> >+ SSLV3_ALERT_BAD_CERTIFICATE
>
> Thanks for filing this!
>
> Yeah I think it's likely, this looks like a more specific and accurate
> error is now reported in this case, either due to the Go TLS library, or
> OpenSSL (which the tests use because they're written in Python).
>
> I have a patch in the `next` branch that should update the test
> accordingly:
>
> https://blitiri.com.ar/git/r/kxd/c/ca7d96cc6088cddbdd9904cc8de8192b417a9340/
>
> https://blitiri.com.ar/git/r/kxd/c/ca7d96cc6088cddbdd9904cc8de8192b417a9340.patch
>
> Would you mind giving it a try? It should solve the problem.
>
I have uploaded the patch in kxd/0.15-4.1.
BTW I see this package doesn't have the Built-Using field (or
Static-Built-Using more correctly) to track the embedded Go toolchain
version, although it has `Built-Using: ${misc:Built-Using}` in
debian/control file. Would you like to improve that a bit?
--
Shengjing Zhu
Bug#1050216: cpu-features: FTBFS on armhf, armel "Including cpuinfo_aarch64.h from a non-aarch64 target"
Control: severity -1 important On Tue, Aug 22, 2023 at 4:21 PM Emanuele Rocca wrote: > > Source: cpu-features > Version: 0.7.0-1 > Severity: serious > Tags: sid trixie ftbfs > User: debian-...@lists.debian.org > Usertags: armhf armel > > Hi, > > cpu-features fails to build on armhf and armel with the following error: > > In file included from /<>/test/cpuinfo_aarch64_test.cc:15: > /<>/test/../include/cpuinfo_aarch64.h:155:2: error: #error > "Including cpuinfo_aarch64.h from a non-aarch64 target." > 155 | #error "Including cpuinfo_aarch64.h from a non-aarch64 target." > | ^ > make[3]: *** [test/CMakeFiles/cpuinfo_aarch64_test.dir/build.make:79: > test/CMakeFiles/cpuinfo_aarch64_test.dir/cpuinfo_aarch64_test.cc.o] Error 1 > make[3]: Leaving directory '/<>/obj-arm-linux-gnueabi' > make[2]: *** [CMakeFiles/Makefile2:1400: > test/CMakeFiles/cpuinfo_aarch64_test.dir/all] Error 2 I can't reproduce it on abel.debian.org https://db.debian.org/machines.cgi?host=abel I assume you are cross building, or running it on an armhf/armel container on arm64 host. -- Shengjing Zhu
Bug#1050168: FTBFS: test_no_local_cert: tlsv13 alert certificate required
Source: kxd Version: 0.15-4 Severity: serious Tags: ftbfs X-Debbugs-Cc: albert...@blitiri.com.ar, z...@debian.org I'm not sure if it's related to golang-defaults -> golang-1.21 recently. tests/run_tests -b ...F Stderr: /usr/lib/python3.11/unittest/case.py:622: ResourceWarning: unclosed with outcome.testPartExecutor(self): .. == FAIL: test_no_local_cert (__main__.TrickyRequests.test_no_local_cert) No local certificate. -- Traceback (most recent call last): File "/<>/tests/run_tests", line 357, in test_no_local_cert conn.getresponse() File "/usr/lib/python3.11/http/client.py", line 1378, in getresponse response.begin() File "/usr/lib/python3.11/http/client.py", line 318, in begin version, status, reason = self._read_status() ^^^ File "/usr/lib/python3.11/http/client.py", line 279, in _read_status line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1") ^^ File "/usr/lib/python3.11/socket.py", line 706, in readinto return self._sock.recv_into(b) ^^^ File "/usr/lib/python3.11/ssl.py", line 1278, in recv_into return self.read(nbytes, buffer) ^ File "/usr/lib/python3.11/ssl.py", line 1134, in read return self._sslobj.read(len, buffer) ^^ ssl.SSLError: [SSL: TLSV13_ALERT_CERTIFICATE_REQUIRED] tlsv13 alert certificate required (_ssl.c:2576) During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/<>/tests/run_tests", line 360, in test_no_local_cert self.assertEqual(err.reason, "SSLV3_ALERT_BAD_CERTIFICATE") AssertionError: 'TLSV13_ALERT_CERTIFICATE_REQUIRED' != 'SSLV3_ALERT_BAD_CERTIFICATE' - TLSV13_ALERT_CERTIFICATE_REQUIRED + SSLV3_ALERT_BAD_CERTIFICATE Stdout: Launching server: /<>/out/kxd --data_dir=/tmp/kxdtest-y_lm39pn/config-server-u2ol6sph/data --key=/tmp/kxdtest-y_lm39pn/config-server-u2ol6sph/key.pem --cert=/tmp/kxdtest-y_lm39pn/config-server-u2ol6sph/cert.pem --logfile=/tmp/kxdtest-y_lm39pn/config-server-u2ol6sph/log --hook=/tmp/kxdtest-y_lm39pn/config-server-u2ol6sph/hook -- Ran 10 tests in 3.009s FAILED (failures=1)
Bug#1049983: panic: connection already exists
Control: severity -1 grave
On Fri, Aug 18, 2023 at 4:51 AM Yuri D'Elia wrote:
>
> Package: syncthing
> Version: 1.19.2~ds1-2
> Severity: normal
>
> With 1.19.2~ds1-2 syncthing panis immediately on the first connection
> with the following error:
>
> | goroutine 685 [select]:
> |
> github.com/syncthing/syncthing/lib/fs.(*BasicFilesystem).watchLoop(0xc0002ec180,
> {0x12318d0, 0xc00066f7c0}, {0x1221680, 0x1}, {0xc00270ca00, 0x1, 0x1},
> 0xc0026a6480, 0xc0005f1080, ...)
> | github.com/syncthing/syncthing/lib/fs/basicfs_watch.go:81 +0x13d
> | created by github.com/syncthing/syncthing/lib/fs.(*BasicFilesystem).Watch
> in goroutine 836
> | github.com/syncthing/syncthing/lib/fs/basicfs_watch.go:59 +0x453
> | panic: connection already exists
>
> Rolling back to 1.19.2~ds1-1+b5 and keeping everything else the same the
> problem disappears...
Thanks for the report, I'm raising the severity to prevent it
migrating to testing.
--
Shengjing Zhu
Bug#1049946: RM: golang-github-labstack-echo.v3 -- RoQA; superseded by golang-github-labstack-echo
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: golang-github-labstack-echo...@packages.debian.org, z...@debian.org Control: affects -1 + src:golang-github-labstack-echo.v3 golang-github-labstack-echo has been updated to 4.x, which obsoleted the v2 and v3.
Bug#1049945: RM: golang-github-labstack-echo.v2 -- RoQA; superseded by golang-github-labstack-echo
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: golang-github-labstack-echo...@packages.debian.org, z...@debian.org Control: affects -1 + src:golang-github-labstack-echo.v2 golang-github-labstack-echo has been updated to 4.x, which obsoleted the v2 and v3.
Bug#1042736: golang-github-dgrijalva-jwt-go-dev: Broken transitional package
Control: affects -1 - go-exploitdb Hi Adrian Bunk, Please drop the Dep-Wait on buildd for go-exploitdb. Thanks. -- Shengjing Zhu
Bug#1043436: RM: packer -- ROM; license is changed to BUSL-1.1 (non-free)
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: pac...@packages.debian.org, z...@debian.org Control: affects -1 + src:packer This project's license is changed from MPL to BUSL-1.1, which is not DFSG anymore. See https://github.com/hashicorp/packer/commit/19055df3ec612ab556aa48e8eac2cb2d401fbab5 And https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license
Bug#1043118: victoriametrics: FTBFS: test failure
On Thu, Aug 10, 2023 at 5:57 PM Guillem Jover wrote: > > Hi! > I cannot reproduce this one on my sid chroot, but another error > completely different in TestMarshalUnmarshalInt64Array. > This is a flaky test, I have reported it to upstream and it has been fixed. https://github.com/VictoriaMetrics/VictoriaMetrics/issues/3683 -- Shengjing Zhu
Bug#1043371: RM: golang-github-elisescu-pty -- RoQA; unnecessary fork, changes have been merged back
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: golang-github-elisescu-...@packages.debian.org, z...@debian.org Control: affects -1 + src:golang-github-elisescu-pty No reverse dependency. Changes have been merged in golang-github-creack-pty-dev.
Bug#1040507: Default GOTOOLCHAIN value in Go1.21
Hi, As Go1.21 is to be released recently, I'd like to know what value we shall set for GOTOOLCHAIN env. The default value is auto, which means it will download the newer toolchain if go.mod ——_explicitly_ says so. See https://go.dev/doc/toolchain for details. Please be aware that it doesn't affect how we build Go packages, as dh-golang will set GOTOOLCHAIN to local to prevent it from accessing the network. So here we only discuss the user experience when using the Go toolchain itself. At #1040507, users are concerned if the downloaded binaries are cryptographically verified. Yes, they are verified the same as Go libraries. If you disable GOSUMDB, it will not be verified, but this means all the Go libraries are not verified as well and we won't disable that by default. Users may have concerns about privacy, but there are already envs like GOPROXY, which is set to https://proxy.golang.org. I don't see much value to change GOPROXY to "off" or other values, as it really hurts the development experience. So if users would change GOPROXY env for privacy reason, I would expect them to change GOTOOLCHAIN as well. (Actually if GOPROXY is set to off, go won't download newer toolchains.) Also I don't see much security concerns as if upstream does evil in their binary releases I would be much concerned about their source which is much harder to audit. Another thought is we always release very old versions in Debian stable. For example we just released Debian 12, which has Go1.19, but Go1.19 is to be EOL in the next few weeks when Go1.21 is released. Allowing Go to download a newer toolchain by default would just make such an old version more useful... I incline to leave the GOTOOLCHAIN value as is, any thoughts? -- Shengjing Zhu
Bug#1036256: golang-github-pin-tftp: FTBFS in testing
On Mon, Jul 31, 2023 at 3:31 AM Thiago Andrade wrote: > > I tested this package on an amd64 PorterBox and the bug seems to have > been resolved by disabling two tests. > I've attached this diff, feel free to test it and upload it as soon as > possible. This doesn't make sense. Could you elaborate why these tests fail and should be skipped? Just disabling tests without explanation doesn't make this package less buggy. -- Shengjing Zhu
Bug#1042542: RM: golang-github-influxdata-tail -- RoQA; unnecessary fork, can be replaced by golang-github-nxadm-tail
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: golang-github-influxdata-t...@packages.debian.org, z...@debian.org Control: affects -1 + src:golang-github-influxdata-tail No reverse dependency. golang-github-nxadm-tail is better.
Bug#1042375: RM: golang-github-marten-seemann-qtls-go1-19 -- RoQA; merged in golang-github-lucas-clemente-quic-go
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: golang-github-marten-seemann-qtls-go1...@packages.debian.org, z...@debian.org Control: affects -1 + src:golang-github-marten-seemann-qtls-go1-19 This package was merged in golang-github-lucas-clemente-quic-go, meanwhile it is for golang-1.19, which is no longer the default one.
Bug#1042089: src:golang-defaults: fails to migrate to testing for too long: triggers autopkgtest failure on armhf
On Thu, Jul 27, 2023 at 2:51 AM David Kalnischkies wrote: > > On Wed, Jul 26, 2023 at 04:48:55PM +0200, Paul Gevers wrote: > > [2]. Hence, I am filing this bug. The version in unstable triggers an > > autopkgtest failure in vim-youcompleteme on armhf. > > This used to be the case for armel, too, until today, which had gccgo-13 > 13.1.0-9 migrate to testing – the day before it failed with 13.1.0-6. > armhf seems to have followed up just now with a passing grade: > https://ci.debian.net/packages/v/vim-youcompleteme/testing/armhf/ Yes, I'm waiting for gcc-13 to migrate. See my previous trigger with gcc-13 from unstable. https://ci.debian.net/user/zhsj/jobs?package=ycmd -- Shengjing Zhu
Bug#967375: gcin: depends on deprecated GTK 2
Control: tags -1 + wontfix On Sat, Jul 22, 2023 at 11:39 PM Bastian Germann wrote: > > Please just drop gcin-gtk2-immodule. > All gtk2 input method modules are supposed to be the last ones to be removed from Debian. Please see smcv's last paragraph. -- Shengjing Zhu
Bug#1041254: docker.io: FTBFS: test failures
Control: forwarded -1 https://github.com/moby/moby/pull/45972 On Sun, Jul 16, 2023 at 10:51 PM Sebastian Ramacher wrote: > > Source: docker.io > Version: 20.10.24+dfsg1-1 > Severity: serious > Tags: ftbfs sid trixie > Justification: fails to build from source (but built successfully in the past) > > https://buildd.debian.org/status/fetch.php?pkg=docker.io=amd64=20.10.24%2Bdfsg1-1%2Bb4=1689240350=0 > FTR, it's caused by golang-1.20 1.20.6-1, a security patch release which restricts http header. Should be fixed by https://github.com/moby/moby/pull/45972 -- Shengjing Zhu
Bug#1030932: golang-github-go-enry-go-license-detector: FTBFS on mipsel: test failures
Control: reopen -1 Hi, On Thu, Jul 13, 2023 at 6:09 PM Pirate Praveen wrote: > > On Thu, 9 Feb 2023 14:40:48 +0100 Sebastian Ramacher > wrote: > > Source: golang-github-go-enry-go-license-detector > > Version: 4.3.0+git20221007.a3a1cc6-1 > > Severity: serious > > Tags: ftbfs > > Justification: fails to build from source (but built successfully in > the past) > > > > > https://buildd.debian.org/status/fetch.php?pkg=golang-github-go-enry-go-license-detector=mipsel=4.3.0%2Bgit20221007.a3a1cc6-1%2Bb2=1675941345=0 > > > > This looks like a temporary error, last build was passing > > https://buildd.debian.org/status/fetch.php?pkg=golang-github-hhatto-gorst=mipsel=0.0%7Egit20181029.ca9f730-2%2Bb6=1681037294=0 You look at the wrong log, it's golang-github-hhatto-gorst, not golang-github-go-enry-go-license-detector. It FTBFS on buildd currently. -- Shengjing Zhu
Bug#1022957: golang-github-blynn-nex: diff for NMU version 0.0.0+git.2021.03.30.1a3320dab9-2.1
On Thu, Jul 13, 2023 at 2:00 AM Boyuan Yang wrote:
>
> Control: tags 1022957 + patch
> Control: tags 1022957 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for golang-github-blynn-nex (versioned as
> 0.0.0+git.2021.03.30.1a3320dab9-2.1) and
> uploaded it to DELAYED/14. Please feel free to tell me if I
> should delay it longer.
>
> Regards.
>
> diff -Nru
> golang-github-blynn-nex-0.0.0+git.2021.03.30.1a3320dab9/debian/changelog
> golang-github-blynn-nex-0.0.0+git.2021.03.30.1a3320dab9/debian/changelog
> --- golang-github-blynn-nex-0.0.0+git.2021.03.30.1a3320dab9/debian/changelog
> 2022-11-01 08:33:32.0 -0400
> +++ golang-github-blynn-nex-0.0.0+git.2021.03.30.1a3320dab9/debian/changelog
> 2023-07-12 13:51:55.0 -0400
> @@ -1,3 +1,11 @@
> +golang-github-blynn-nex (0.0.0+git.2021.03.30.1a3320dab9-2.1) unstable;
> urgency=medium
> +
> + * Non-maintainer upload.
> + * debian/control: Mark package nex to conflict with package nvi
> +due to file conflict of /usr/bin/nex. (Closes: #1022957)
> +
> + -- Boyuan Yang Wed, 12 Jul 2023 13:51:55 -0400
> +
> golang-github-blynn-nex (0.0.0+git.2021.03.30.1a3320dab9-2) unstable;
> urgency=medium
>
>* Re-upload source-only.
> diff -Nru
> golang-github-blynn-nex-0.0.0+git.2021.03.30.1a3320dab9/debian/control
> golang-github-blynn-nex-0.0.0+git.2021.03.30.1a3320dab9/debian/control
> --- golang-github-blynn-nex-0.0.0+git.2021.03.30.1a3320dab9/debian/control
> 2022-11-01 08:33:32.0 -0400
> +++ golang-github-blynn-nex-0.0.0+git.2021.03.30.1a3320dab9/debian/control
> 2023-07-12 13:51:40.0 -0400
> @@ -20,6 +20,8 @@
> ${shlibs:Depends},
> Suggests:
> graphviz,
> +Conflicts:
> + nvi,
> Description: lexer similar to Lex/Flex - cli
> Nex is a lexer similar to Lex/Flex that:
>* generates Go code instead of C code
This is not right as per debian policy 10.1.
"Two different packages must not install programs with different
functionality but with the same filenames".
Please cancel the NMU.
--
Shengjing Zhu
Bug#1040157: ITP: golang-github-azuread-microsoft-authentication-library-for-go -- Microsoft Authentication Library (MSAL) for Go
Control: merge -1 1039471 On Sun, Jul 2, 2023 at 11:57 PM Félix Sipma wrote: > > Package: wnpp > Severity: wishlist > Owner: Félix Sipma > > * Package name: > golang-github-azuread-microsoft-authentication-library-for-go > Version : 0.6.0-1 > Upstream Author : Microsoft > * URL : > https://github.com/AzureAD/microsoft-authentication-library-for-go > * License : Expat > Programming Lang: Go > Description : Microsoft Authentication Library (MSAL) library for Go This has already been packaged, and it's waiting in NEW. https://ftp-master.debian.org/new/golang-github-azuread-microsoft-authentication-library-for-go_1.0.0-1.html -- Shengjing Zhu
Bug#1039022: obsoleted fork, can be replaced by golang-github-creack-pty-dev
Source: golang-github-elisescu-pty Version: 1.1.9-1 Severity: serious X-Debbugs-Cc: z...@debian.org This fork only contains one change: https://github.com/elisescu/pty/commit/b36ef7cd (Add a Setsize function to set the size of the terminal) This is already merged in https://github.com/creack/pty/commit/f4f01f59 Reverse dependencies should migrate to golang-github-creack-pty-dev. -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (500, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/16 CPU threads; PREEMPT) 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
Bug#1038902: docker.io: FTBFS skip btrfs
On Fri, Jun 23, 2023 at 4:51 PM Bastien Roucariès wrote: > To test create a btrfs filesystem and mount in on your schroot root or > pbuilder root. > That's far from what I can do. Setting up a non normal build system is not something we can support. And throwing non non-working patch and tagging the bug with patch is not appreciated. -- Shengjing Zhu
Bug#1038902: docker.io: FTBFS skip btrfs
Control: tags -1 - patch On Fri, Jun 23, 2023 at 4:42 PM Shengjing Zhu wrote: > > Control: severity -1 wishlist > Control: tags -1 patch > Fixing control command... -- Shengjing Zhu
Bug#1038902: docker.io: FTBFS skip btrfs
Control: severity -1 wishlist Control: tags -1 patch On Fri, Jun 23, 2023 at 5:33 AM Bastien Roucariès wrote: > > Source: docker.io > Severity: serious > Tags: ftbfs > control: tags -1 + patch > Justification: FTBFS > > Dear Maintainer, > > I had applied the following patch for compiling under btrfs for buster. Could > you refresh and apply for other version The patch doesn't apply to the current version. Meanwhile it doesn't FTBFS on buildd. -- Shengjing Zhu
Bug#1038793: unmaintained fork for jwt-go
Source: golang-github-form3tech-oss-jwt-go Version: 3.2.3-1 Severity: serious X-Debbugs-Cc: z...@debian.org I don't see any reason to introduce another unmaintained fork of jwt-go. Since it hasn't be in testing before, no existing code depends on that. New code should use https://tracker.debian.org/pkg/golang-github-golang-jwt-jwt -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (500, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/16 CPU threads; PREEMPT) 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
Bug#1037927: ITP: fuse -- bazil.org/fuse - With macOS support and its own import path so replace directives aren't necessary
On Thu, Jun 15, 2023 at 3:29 AM Félix Sipma wrote: > > Sorry about this, the message was auto-generated by dh-make-golang and I > forgot to edit the package name in the ITP. I intend to use the usual > golang naming "golang-github-anacrolix-fuse". FWIW, You could use the `dh-make-golang -type library` option. -- Shengjing Zhu
Bug#1037480: autopkgtest fails with golang-1.20
Source: ycmd Version: 0+20230103+gitf53e7ac+ds-1 Severity: serious X-Debbugs-Cc: z...@debian.org Control: forworded -1 https://github.com/ycm-core/ycmd/commit/01a1f543 I've updated golang-defaults to 1.20 in unstable, your package's autopkgtest fails with that. I've sent the fix to upstream, could you backport the commit or package a new snapshot. https://github.com/ycm-core/ycmd/commit/01a1f543 -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (500, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/16 CPU threads; PREEMPT) 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
Bug#1037035: FTBFS due to tests relying on running redis server
Source: beaker Version: 1.12.1-1 Severity: serious Tags: ftbfs patch X-Debbugs-Cc: z...@debian.org The tests need a running redis server. I suggests ignore it just like the mongodb one. Please see the patch. diff -Nru beaker-1.12.1/debian/changelog beaker-1.12.1/debian/changelog --- beaker-1.12.1/debian/changelog 2023-02-10 02:37:53.0 +0800 +++ beaker-1.12.1/debian/changelog 2023-06-02 19:23:50.0 +0800 @@ -1,3 +1,9 @@ +beaker (1.12.1-1.1) unstable; urgency=medium + + * Exclude tests relying on running redis server. + + -- Shengjing Zhu Fri, 02 Jun 2023 19:23:50 +0800 + beaker (1.12.1-1) unstable; urgency=medium * New upstream release diff -Nru beaker-1.12.1/debian/rules beaker-1.12.1/debian/rules --- beaker-1.12.1/debian/rules 2023-02-10 02:37:53.0 +0800 +++ beaker-1.12.1/debian/rules 2023-06-02 19:23:37.0 +0800 @@ -1,6 +1,6 @@ #! /usr/bin/make -f export PYBUILD_NAME=beaker -export PYBUILD_TEST_ARGS=--ignore=tests/test_memcached.py --ignore=tests/test_managers/test_ext_mongodb.py -k 'not test_cookie_expires_different_locale' +export PYBUILD_TEST_ARGS=--ignore=tests/test_memcached.py --ignore-glob=tests/test_managers/test_ext_*.py -k 'not test_cookie_expires_different_locale' %: dh $@ --with python3 --buildsystem=pybuild
Bug#1036704: unblock: dhcpcd5/9.4.1-22
On Wed, May 24, 2023 at 9:57 PM Shengjing Zhu wrote: > [ Checklist ] > [x] attach debdiff against the package in testing Sorry, missing attachment... dhcpcd5_9.4.1-22.debdiff Description: Binary data
Bug#1036704: unblock: dhcpcd5/9.4.1-22
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: dhcp...@packages.debian.org, z...@debian.org, martin-eric.rac...@iki.fi Control: affects -1 + src:dhcpcd5 Please unblock package dhcpcd5 [ Reason ] The packages fails to run on ppc64el (syscall is blocked by seccomp policy). And `dhcpcd -U` command also fails to run on all arch (newfstatat syscall introduced by glibc is blocked by seccomp policy) While trying to run autopkgtests to verify these issues, I find it contains isolation-machine tests, which never run Debian infra, but are broken. So this version contains fixes for autopkgtests too. [ Impact ] Without the unblock, the package is not functional entirely on ppc64el, and one subcommand is not functional on all arch. [ Tests ] It has autopkgtests, but non-trival ones need isolation-machine. I've run them on Ubuntu autopkgtest infra. [ Risks ] Code is trival and easy to review. [ 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 [ Other info ] None unblock dhcpcd5/9.4.1-22
Bug#1034465: reportbug: dhcpcd -U results in "Bad system call"
The relevant fix is https://github.com/NetworkConfiguration/dhcpcd/commit/38befd4e
Bug#1036662: killed by SIGSYS on ppc64el
Source: dhcpcd5 Version: 9.4.1-21 Severity: important X-Debbugs-Cc: z...@debian.org When running on ppc64el, it's killed by SIGSYS due to seccomp policy. It has been fixed in https://github.com/NetworkConfiguration/dhcpcd/pull/181
Bug#1036098: autopkgtests fail when testbed has running dns server
On Tue, May 23, 2023 at 2:20 PM Martin-Éric Racine wrote: [...] > > > I merged your change to the dnsmasq configuration. For some reason, it > > > makes 'piuparts' fail in the Salsa pipeline. > > > > The pipeline failure is not related. It's because apt no longer > > depends adduser. I know it's been discussed elsewhere, but I can't > > remember (maybe on IRC). Somebody is working on it, I think the plan > > is to mark adduser essential. > > You could just re-trigger the pipeline for your old commit to confirm. > > It still fails. I mean it fails without this change. You can see https://salsa.debian.org/debian/dhcpcd5/-/jobs/4238885 also fails, which is for your last good commit https://salsa.debian.org/debian/dhcpcd5/-/commit/e7f24aa4 -- Shengjing Zhu
Bug#1036098: autopkgtests fail when testbed has running dns server
On Sun, May 21, 2023 at 1:20 AM Martin-Éric Racine wrote: > > On Mon, May 15, 2023 at 4:25 PM Shengjing Zhu wrote: > > > > On Mon, May 15, 2023 at 8:55 PM Martin-Éric Racine > > wrote: > > > However, doing this one week away from Debian's final freeze is the > > > entirely wrong approach. This should have been done at least 2 months > > > ago, before the soft freeze started. > > > > I'm aware of the timeline. Thus I filed with normal severity that > > doesn't need to be fixed for Bookworm. And important for issue > > relevant for Bookworm. > > Debian doesn't run these autopkgtest at all, since the debci infra > > doesn't support isolation-machine. > > I merged your change to the dnsmasq configuration. For some reason, it > makes 'piuparts' fail in the Salsa pipeline. The pipeline failure is not related. It's because apt no longer depends adduser. I know it's been discussed elsewhere, but I can't remember (maybe on IRC). Somebody is working on it, I think the plan is to mark adduser essential. You could just re-trigger the pipeline for your old commit to confirm. -- Shengjing Zhu
Bug#1036164: nmu: fcitx5-zhuyin_5.0.11-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: fcitx5-zhu...@packages.debian.org, z...@debian.org Control: affects -1 + src:fcitx5-zhuyin nmu fcitx5-zhuyin_5.0.11-1 . ANY . unstable . -m "Rebuild with libpinyin/2.8.1 (Closes: #1036163)" There must be better way to track this binary file format, but I'm not sure how to implement it. binNMU might be the easiest way currently.
Bug#1036163: failed.mmap /usr/share/fcitx5/zhuyin/gb_char.bin failed
Package: fcitx5-zhuyin Version: 5.0.11-1 Severity: grave X-Debbugs-Cc: z...@debian.org When switching to fcitx5-zhuyin, fcitx5 segfault failed.mmap /usr/share/fcitx5/zhuyin/gb_char.bin failed! #0 0x7fd7cce595f6 in pinyin::SubPhraseIndex::load (this=0x55f4df550dc0, chunk=chunk@entry=0x55f4df550d90, offset=16, offset@entry=0, end=0) at storage/phrase_index.cpp:353 #1 0x7fd7cce597e9 in pinyin::FacadePhraseIndex::load (this=this@entry=0x55f4df53ba40, phrase_index=phrase_index@entry=1 '\001', chunk=chunk@entry=0x55f4df550d90) at storage/phrase_index.cpp:243 #2 0x7fd7cce99887 in _load_phrase_library (system_dir=, user_dir=0x55f4df52f2e0 "/home/zsj/.local/share/fcitx5/zhuyin", phrase_index=0x55f4df53ba40, table_info=0x55f4df540888) at ./src/zhuyin.cpp:208 #3 0x7fd7cce9e7a5 in zhuyin_init (systemdir=, userdir=) at ./src/zhuyin.cpp:332 Rebuilding the package fixes the problem. gb_char.bin is generated when building fcitx5-zhuyin, using /usr/bin/gen_binary_files from libpinyin-utils/2.7.92, which can't be read by libzhuyin15/2.8.1. So I think the problem is libpinyin changes the binary format from 2.7.92 to 2.8.1. -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (500, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/16 CPU threads; PREEMPT) 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 fcitx5-zhuyin depends on: ii libc6 2.36-9 ii libfcitx5config6 5.0.21-3 ii libfcitx5core75.0.21-3 ii libfcitx5utils2 5.0.21-3 ii libgcc-s1 12.2.0-14 ii libglib2.0-0 2.74.6-2 ii libstdc++612.2.0-14 ii libzhuyin15 2.8.1-1 Versions of packages fcitx5-zhuyin recommends: ii fcitx5 5.0.21-3 fcitx5-zhuyin suggests no packages. -- no debconf information
Bug#1036098: autopkgtests fail when testbed has running dns server
On Mon, May 15, 2023 at 8:55 PM Martin-Éric Racine wrote: > However, doing this one week away from Debian's final freeze is the > entirely wrong approach. This should have been done at least 2 months > ago, before the soft freeze started. I'm aware of the timeline. Thus I filed with normal severity that doesn't need to be fixed for Bookworm. And important for issue relevant for Bookworm. Debian doesn't run these autopkgtest at all, since the debci infra doesn't support isolation-machine. -- Shengjing Zhu
Bug#1036098: autopkgtests fail when testbed has running dns server
Source: dhcpcd5 Version: 9.4.1-21 Severity: normal X-Debbugs-Cc: z...@debian.org When systemd-resolved is used in the testbed, the provided dnsmasq config in debian/tests/common-ntp-servers-from-dhcp causes dnsmasq failed to start. Because systemd-resolved already listens on port 53 on lo interface. This can be workaround by adding `bind-interfaces` to the generated dnsmasq config (otherwise dnsmasq listens on 0.0.0.0 even it has interface=veth0 config). For clarify, I'm triaging the failed autopkgtests on Ubuntu, and will submit patch or MR when I've done them all.
Bug#1036092: ntp hook is not compatible with ntpsec
On Mon, May 15, 2023 at 7:36 PM Martin-Éric Racine wrote: > > On Mon, May 15, 2023 at 2:32 PM Shengjing Zhu wrote: > > > > On Mon, May 15, 2023 at 7:23 PM Martin-Éric Racine > > wrote: > > > > > > On Mon, May 15, 2023 at 2:13 PM Shengjing Zhu wrote: > > > > > > > > On Mon, May 15, 2023 at 7:09 PM Martin-Éric Racine > > > > wrote: > > > > > > > > > > On Mon, May 15, 2023 at 1:58 PM Shengjing Zhu wrote: > > > > > > > > > > > > On Mon, May 15, 2023 at 6:53 PM Martin-Éric Racine > > > > > > wrote: > > > > > > > > > > > > > > On Mon, May 15, 2023 at 1:36 PM Shengjing Zhu > > > > > > > wrote: > > > > > > > > Package: dhcpcd-base > > > > > > > > Version: 9.4.1-21 > > > > > > > > Severity: important > > > > > > > > X-Debbugs-Cc: z...@debian.org > > > > > > > > > > > > > > > > For bookworm ntpsec has replaced the old ntp. > > > > > > > > See https://bugs.debian.org/1003966 > > > > > > > > > > > > > > > > ntpsec (1.2.1+dfsg1-5) experimental; urgency=medium > > > > > > > > . > > > > > > > >* Add ntpd.service alias > > > > > > > >* Add ntp transitional packages (Closes: 1003966) > > > > > > > > > > > > > > > > Now the hook is wrong to assume the existence of /etc/ntp.conf > > > > > > > > and > > > > > > > > /run/ntp.conf.dhcp > > > > > > > > > > > > > > Can you file a bug report upstream? As of 10.0.1-1 (pending > > > > > > > upload), > > > > > > > I have deprecated Debian's NTP hooks and use upstream's NTP hooks > > > > > > > instead. Any missing support for alternative NTP daemons would be > > > > > > > best > > > > > > > filed there. > > > > > > > > > > > > > > > > > > > It's filed for version 9.4.1-21, which is going to be included in > > > > > > Debian Bookworm. However ntpd has been replaced by ntpsec in Debian > > > > > > Bookworm. So the hook is wrong now. And the hook is a Debian > > > > > > specific > > > > > > patch. > > > > > > If you don't want to continue supporting ntpsec, I would suggest > > > > > > removing this non-working hook for Bookworm (and its autopkgtest). > > > > > > > > > > I'm not gonna introduce any change to the package for Bookworm this > > > > > late into the freeze. > > > > > > > > > > > > > However this is a real bug for Bookworm. Shipping non-working parts is > > > > worse than non-support. > > > > ntpsec taking over ntpd already happens for Bookworm. > > > > > > If you want to have ntpsec support in Bookworm, please submit a patch > > > to add ntpsec support to the current hooks and ask the Bookworm > > > release manager for an exemption to the freeze. > > > > TBH I really don't use ntpsec. I just looked through this package and > > its autopkgtest. > > > > Why do you think patching ntpsec is the right thing here? > > Please read again. I'm pretty sure I have read it carefully. Support for various ntp implementations is located in dhcpcd's hook dir. It's not any ntp implementation's responsibility to integrate with dhcpcd. > > > There is no old ntpd in Bookworm anymore, it's already been removed. > > You include a non-working patch in dhcpcd and an always failing > > autopkgtest. What's the benefit for the quality? > > I'm not interested in getting into a debate about this. I'm not sure why you are so resistant about this. Are you worried about the extra works? I certainly can work this for you and file unblock request. But since the strong maintainship in Debian, it still needs you to agree on. -- Shengjing Zhu
Bug#1036092: ntp hook is not compatible with ntpsec
On Mon, May 15, 2023 at 7:23 PM Martin-Éric Racine wrote: > > On Mon, May 15, 2023 at 2:13 PM Shengjing Zhu wrote: > > > > On Mon, May 15, 2023 at 7:09 PM Martin-Éric Racine > > wrote: > > > > > > On Mon, May 15, 2023 at 1:58 PM Shengjing Zhu wrote: > > > > > > > > On Mon, May 15, 2023 at 6:53 PM Martin-Éric Racine > > > > wrote: > > > > > > > > > > On Mon, May 15, 2023 at 1:36 PM Shengjing Zhu wrote: > > > > > > Package: dhcpcd-base > > > > > > Version: 9.4.1-21 > > > > > > Severity: important > > > > > > X-Debbugs-Cc: z...@debian.org > > > > > > > > > > > > For bookworm ntpsec has replaced the old ntp. > > > > > > See https://bugs.debian.org/1003966 > > > > > > > > > > > > ntpsec (1.2.1+dfsg1-5) experimental; urgency=medium > > > > > > . > > > > > >* Add ntpd.service alias > > > > > >* Add ntp transitional packages (Closes: 1003966) > > > > > > > > > > > > Now the hook is wrong to assume the existence of /etc/ntp.conf and > > > > > > /run/ntp.conf.dhcp > > > > > > > > > > Can you file a bug report upstream? As of 10.0.1-1 (pending upload), > > > > > I have deprecated Debian's NTP hooks and use upstream's NTP hooks > > > > > instead. Any missing support for alternative NTP daemons would be best > > > > > filed there. > > > > > > > > > > > > > It's filed for version 9.4.1-21, which is going to be included in > > > > Debian Bookworm. However ntpd has been replaced by ntpsec in Debian > > > > Bookworm. So the hook is wrong now. And the hook is a Debian specific > > > > patch. > > > > If you don't want to continue supporting ntpsec, I would suggest > > > > removing this non-working hook for Bookworm (and its autopkgtest). > > > > > > I'm not gonna introduce any change to the package for Bookworm this > > > late into the freeze. > > > > > > > However this is a real bug for Bookworm. Shipping non-working parts is > > worse than non-support. > > ntpsec taking over ntpd already happens for Bookworm. > > If you want to have ntpsec support in Bookworm, please submit a patch > to add ntpsec support to the current hooks and ask the Bookworm > release manager for an exemption to the freeze. TBH I really don't use ntpsec. I just looked through this package and its autopkgtest. Why do you think patching ntpsec is the right thing here? There is no old ntpd in Bookworm anymore, it's already been removed. You include a non-working patch in dhcpcd and an always failing autopkgtest. What's the benefit for the quality? -- Shengjing Zhu
Bug#1036092: ntp hook is not compatible with ntpsec
On Mon, May 15, 2023 at 7:09 PM Martin-Éric Racine wrote: > > On Mon, May 15, 2023 at 1:58 PM Shengjing Zhu wrote: > > > > On Mon, May 15, 2023 at 6:53 PM Martin-Éric Racine > > wrote: > > > > > > On Mon, May 15, 2023 at 1:36 PM Shengjing Zhu wrote: > > > > Package: dhcpcd-base > > > > Version: 9.4.1-21 > > > > Severity: important > > > > X-Debbugs-Cc: z...@debian.org > > > > > > > > For bookworm ntpsec has replaced the old ntp. > > > > See https://bugs.debian.org/1003966 > > > > > > > > ntpsec (1.2.1+dfsg1-5) experimental; urgency=medium > > > > . > > > >* Add ntpd.service alias > > > >* Add ntp transitional packages (Closes: 1003966) > > > > > > > > Now the hook is wrong to assume the existence of /etc/ntp.conf and > > > > /run/ntp.conf.dhcp > > > > > > Can you file a bug report upstream? As of 10.0.1-1 (pending upload), > > > I have deprecated Debian's NTP hooks and use upstream's NTP hooks > > > instead. Any missing support for alternative NTP daemons would be best > > > filed there. > > > > > > > It's filed for version 9.4.1-21, which is going to be included in > > Debian Bookworm. However ntpd has been replaced by ntpsec in Debian > > Bookworm. So the hook is wrong now. And the hook is a Debian specific > > patch. > > If you don't want to continue supporting ntpsec, I would suggest > > removing this non-working hook for Bookworm (and its autopkgtest). > > I'm not gonna introduce any change to the package for Bookworm this > late into the freeze. > However this is a real bug for Bookworm. Shipping non-working parts is worse than non-support. ntpsec taking over ntpd already happens for Bookworm. -- Shengjing Zhu
Bug#1036092: ntp hook is not compatible with ntpsec
On Mon, May 15, 2023 at 6:53 PM Martin-Éric Racine wrote: > > On Mon, May 15, 2023 at 1:36 PM Shengjing Zhu wrote: > > Package: dhcpcd-base > > Version: 9.4.1-21 > > Severity: important > > X-Debbugs-Cc: z...@debian.org > > > > For bookworm ntpsec has replaced the old ntp. > > See https://bugs.debian.org/1003966 > > > > ntpsec (1.2.1+dfsg1-5) experimental; urgency=medium > > . > >* Add ntpd.service alias > >* Add ntp transitional packages (Closes: 1003966) > > > > Now the hook is wrong to assume the existence of /etc/ntp.conf and > > /run/ntp.conf.dhcp > > Can you file a bug report upstream? As of 10.0.1-1 (pending upload), > I have deprecated Debian's NTP hooks and use upstream's NTP hooks > instead. Any missing support for alternative NTP daemons would be best > filed there. > It's filed for version 9.4.1-21, which is going to be included in Debian Bookworm. However ntpd has been replaced by ntpsec in Debian Bookworm. So the hook is wrong now. And the hook is a Debian specific patch. If you don't want to continue supporting ntpsec, I would suggest removing this non-working hook for Bookworm (and its autopkgtest). -- Shengjing Zhu
Bug#1036092: ntp hook is not compatible with ntpsec
Package: dhcpcd-base Version: 9.4.1-21 Severity: important X-Debbugs-Cc: z...@debian.org For bookworm ntpsec has replaced the old ntp. See https://bugs.debian.org/1003966 ntpsec (1.2.1+dfsg1-5) experimental; urgency=medium . * Add ntpd.service alias * Add ntp transitional packages (Closes: 1003966) Now the hook is wrong to assume the existence of /etc/ntp.conf and /run/ntp.conf.dhcp
Bug#1036085: Please drop Conflicts/Replaces with dhcp-client
On Mon, May 15, 2023 at 4:05 PM Martin-Éric Racine wrote: > > On Mon, May 15, 2023 at 10:42 AM Shengjing Zhu wrote: > > Copying our policy 7.4: > > > > Neither Breaks nor Conflicts should be used unless two packages cannot be > > installed at the same time or installing them both causes one of them to be > > broken or unusable. Having similar functionality or performing the same > > tasks > > as another package is not sufficient reason to declare Breaks or Conflicts > > with that package. > > The Conflicts/Provides isn't there because they provide similar > features. It is there because the backend has no way of selecting > which DHCP client will be used. > But they can be installed together right? then it falls into the policy that Breaks/Conflicts is not the right place. People can just uninstall other clients manually to let the ifupdown to choose the wanted backend. It may have weird use cases like, using different implementations of dhcp client for different hardware interfaces. I believe the policy is there to not restrict the usefulness of different implementations. > This is a case similar to sendmail. I don't think so. The mail-transport-agent packages both ship /usr/sbin/sendmail file. This is allowed and suggested by the policy to use Conflicts/Replaces. -- Shengjing Zhu
Bug#1036085: Please drop Conflicts/Replaces with dhcp-client
Package: dhcpcd-base Version: 9.4.1-21 Severity: normal X-Debbugs-Cc: z...@debian.org It seems you add this because: commit 37b4b03f4d5e598eb2a3b0a58c6eec269b09c585 Add more Conflicts with other DHCP clients interfaces(5) precedence for DHCP method is: dhclient, pump, udhcpc, dhcpcd. We wanna ensure that none of those with a higher priority are installed. We skip pump since it hasn't been in the Debian archive for a long time. However IMO it looks like misuse of Conflicts/Replaces. For example there are not conflict files between isc-dhcp-client and dhcpcd-base, but now they can't be installed together. Yes, people don't need to install two different dhcp clients. But they should have the ability to install them together as long as they don't have real conflicts (same file for example). Copying our policy 7.4: Neither Breaks nor Conflicts should be used unless two packages cannot be installed at the same time or installing them both causes one of them to be broken or unusable. Having similar functionality or performing the same tasks as another package is not sufficient reason to declare Breaks or Conflicts with that package. https://www.debian.org/doc/debian-policy/ch-relationships.html I come across this issue since I find this package's autopkgtest can't be run on Ubuntu. Because their base system has isc-dhcp-client installed (needed by ubuntu-minimal package, which can't be removed). Please remove the Conflicts/Replaces with dhcp-client. (No urgent for Bookworm release, but a new upload to experimental first is much appreciated) Thanks.
Bug#1036078: unblock: docker-registry/2.8.2+ds1-1
+0800
@@ -1,3 +1,14 @@
+docker-registry (2.8.2+ds1-1) unstable; urgency=medium
+
+ * Team upload
+ * New upstream version 2.8.2+ds1
++ CVE-2023-2253: Catalog API endpoint can lead to OOM via malicious user
+ input (Closes: #1035956)
+ * Drop patch merged by upstream
++ 0009-Fix-panic-in-inmemory-driver.patch
+
+ -- Shengjing Zhu Sat, 13 May 2023 23:21:12 +0800
+
docker-registry (2.8.1+ds1-2) unstable; urgency=medium
[ Debian Janitor ]
diff -Nru -w
docker-registry-2.8.1+ds1/debian/patches/0007-Skip-TestRegistryAsCacheMutationAPIs.patch
docker-registry-2.8.2+ds1/debian/patches/0007-Skip-TestRegistryAsCacheMutationAPIs.patch
---
docker-registry-2.8.1+ds1/debian/patches/0007-Skip-TestRegistryAsCacheMutationAPIs.patch
2022-06-29 20:32:34.0 +0800
+++
docker-registry-2.8.2+ds1/debian/patches/0007-Skip-TestRegistryAsCacheMutationAPIs.patch
2023-05-13 23:21:12.0 +0800
@@ -12,10 +12,10 @@
1 file changed, 1 insertion(+)
diff --git a/registry/handlers/api_test.go b/registry/handlers/api_test.go
-index 2d3edc7..a07184b 100644
+index bf037d4..207e167 100644
--- a/registry/handlers/api_test.go
+++ b/registry/handlers/api_test.go
-@@ -2468,6 +2468,7 @@ func createRepository(env *testEnv, t *testing.T,
imageName string, tag string)
+@@ -2728,6 +2728,7 @@ func createRepository(env *testEnv, t *testing.T,
imageName string, tag string)
// Test mutation operations on a registry configured as a cache. Ensure that
they return
// appropriate errors.
func TestRegistryAsCacheMutationAPIs(t *testing.T) {
diff -Nru -w
docker-registry-2.8.1+ds1/debian/patches/0009-Fix-panic-in-inmemory-driver.patch
docker-registry-2.8.2+ds1/debian/patches/0009-Fix-panic-in-inmemory-driver.patch
---
docker-registry-2.8.1+ds1/debian/patches/0009-Fix-panic-in-inmemory-driver.patch
2022-06-29 20:32:34.0 +0800
+++
docker-registry-2.8.2+ds1/debian/patches/0009-Fix-panic-in-inmemory-driver.patch
1970-01-01 08:00:00.0 +0800
@@ -1,23 +0,0 @@
-From: Shengjing Zhu
-Date: Sun, 27 Mar 2022 19:38:07 +0800
-Subject: Fix panic in inmemory driver
-
-Forwarded: https://github.com/distribution/distribution/pull/3615
- registry/storage/driver/inmemory/mfs.go | 3 +++
- 1 file changed, 3 insertions(+)
-
-diff --git a/registry/storage/driver/inmemory/mfs.go
b/registry/storage/driver/inmemory/mfs.go
-index 9a2865f..24eeef9 100644
a/registry/storage/driver/inmemory/mfs.go
-+++ b/registry/storage/driver/inmemory/mfs.go
-@@ -279,6 +279,9 @@ func (f *file) sectionReader(offset int64) io.Reader {
- }
-
- func (f *file) ReadAt(p []byte, offset int64) (n int, err error) {
-+ if offset >= int64(len(f.data)) {
-+ return 0, io.EOF
-+ }
- return copy(p, f.data[offset:]), nil
- }
-
diff -Nru -w docker-registry-2.8.1+ds1/debian/patches/series
docker-registry-2.8.2+ds1/debian/patches/series
--- docker-registry-2.8.1+ds1/debian/patches/series 2022-06-29
20:32:34.0 +0800
+++ docker-registry-2.8.2+ds1/debian/patches/series 2023-05-13
23:21:12.0 +0800
@@ -6,4 +6,3 @@
0006-Skip-TestHTTPChecker.patch
0007-Skip-TestRegistryAsCacheMutationAPIs.patch
0008-Skip-flaky-TestGracefulShutdown-and-TestRegistrySupp.patch
-0009-Fix-panic-in-inmemory-driver.patch
diff -Nru -w docker-registry-2.8.1+ds1/.dockerignore
docker-registry-2.8.2+ds1/.dockerignore
--- docker-registry-2.8.1+ds1/.dockerignore 1970-01-01 08:00:00.0
+0800
+++ docker-registry-2.8.2+ds1/.dockerignore 2023-05-11 18:11:57.0
+0800
@@ -0,0 +1 @@
+bin/
diff -Nru -w docker-registry-2.8.1+ds1/health/doc.go
docker-registry-2.8.2+ds1/health/doc.go
--- docker-registry-2.8.1+ds1/health/doc.go 2022-03-09 01:52:36.0
+0800
+++ docker-registry-2.8.2+ds1/health/doc.go 2023-05-11 18:11:57.0
+0800
@@ -13,7 +13,7 @@
// particularly useful for checks that verify upstream connectivity or
// database status, since they might take a long time to return/timeout.
//
-// Installing
+// # Installing
//
// To install health, just import it in your application:
//
@@ -35,7 +35,7 @@
// After importing these packages to your main application, you can start
// registering checks.
//
-// Registering Checks
+// # Registering Checks
//
// The recommended way of registering checks is using a periodic Check.
// PeriodicChecks run on a certain schedule and asynchronously update the
@@ -84,7 +84,7 @@
// return Errors.new("This is an error!")
// }))
//
-// Examples
+// # Examples
//
// You could also use the health checker mechanism to ensure your application
// only comes up if certain conditions are met, or to allow the developer to
diff -Nru -w docker-registry-2.8.1+ds1/registry/api/v2/descriptors.go
docker-registry-2.8.2+ds1/registry/api/v2/descriptors.go
--- docker-registry-2.8.1+ds1/registry/api/v2/descriptors.go2022-03-09
01:52:36.0 +0800
+++ docker-registry-2.8.2+ds1/registry/api/v2/descriptors.go2023-05
Bug#1034886: docker.io: CVE-2022-37708
On Thu, Apr 27, 2023 at 1:39 AM Moritz Mühlenhoff wrote: > > Source: docker.io > X-Debbugs-CC: t...@security.debian.org > Severity: important > Tags: security > > Hi, > > The following vulnerability was published for docker.io. > > CVE-2022-37708[0]: > | Docker version 20.10.15, build fd82621 is vulnerable to Insecure > | Permissions. Unauthorized users outside the Docker container can > | access any files within the Docker container. > > The only reference here seems to be > upstream: https://github.com/thekevinday/docker_lightman_exploit > > Not sure if this was reported upstream I have talked to Tianon on 2023-02-28, and we concluded that it's not a security issue, just working as expected. Tianon said he will ask someone inside the Docker company. Not sure if they have successfully invalidated this CVE. -- Shengjing Zhu
