Bug#1032004: nmu: packages built by golang-1.15
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: z...@debian.org Hi, Maybe there's bug in the scripts to rebuild for outdated Built-Using. There are still packages built by golang-1.15. $ grep-dctrl -r -s Package -F Built-Using 'golang-1.1[0-8]' /var/lib/apt/lists/*debian_dists_testing_main_binary-amd64_Packages Package: codesearch Package: ffuf Package: tmpl Package: fernet-go Package: blueprint-tools Package: cli-spinner Package: ripper Package: golang-statik Package: golang-github-rsc-devweb Package: goxkcdpwgen Package: heartbleeder Package: hellfire Package: opensmtpd-filter-rspamd Package: opensmtpd-filter-senderscore
Re: Updating python3-xlrd for pandas 1.5 compatibility
On Sat, Feb 25, 2023 at 2:51 AM Shengjing Zhu wrote: > > On Sat, Feb 25, 2023 at 2:33 AM Paul Gevers wrote: > > pandas has a quite extensive autopkgtest, doesn't it > > cover this use case? Apparently you knew this earlier, why do you bring > > this up now? > > Seems a bit unfortunate when pandas updates the version. > > https://salsa.debian.org/science-team/pandas/-/blob/debian/1.5.3+dfsg-2/pandas/tests/io/excel/test_xlrd.py#L13 > https://salsa.debian.org/science-team/pandas/-/blob/debian/1.5.3+dfsg-2/debian/tests/control#L51 > Reading the comments in test/control, seems python3-blosc and python3-snappy are also not compatible with the version of pandas. -- Shengjing Zhu
Re: Updating python3-xlrd for pandas 1.5 compatibility
On Sat, Feb 25, 2023 at 2:33 AM Paul Gevers wrote: > pandas has a quite extensive autopkgtest, doesn't it > cover this use case? Apparently you knew this earlier, why do you bring > this up now? Seems a bit unfortunate when pandas updates the version. https://salsa.debian.org/science-team/pandas/-/blob/debian/1.5.3+dfsg-2/pandas/tests/io/excel/test_xlrd.py#L13 https://salsa.debian.org/science-team/pandas/-/blob/debian/1.5.3+dfsg-2/debian/tests/control#L51 A RC bug for python3-xlrd was missing when pandas updated to 1.4.3+dfsg-1. -- Shengjing Zhu
Re: Updating python3-xlrd for pandas 1.5 compatibility
On Sat, Feb 25, 2023 at 2:51 AM Shengjing Zhu wrote: > > On Sat, Feb 25, 2023 at 2:33 AM Paul Gevers wrote: > > pandas has a quite extensive autopkgtest, doesn't it > > cover this use case? Apparently you knew this earlier, why do you bring > > this up now? > > Seems a bit unfortunate when pandas updates the version. > > https://salsa.debian.org/science-team/pandas/-/blob/debian/1.5.3+dfsg-2/pandas/tests/io/excel/test_xlrd.py#L13 > https://salsa.debian.org/science-team/pandas/-/blob/debian/1.5.3+dfsg-2/debian/tests/control#L51 > Reading the comments in test/control, seems python3-blosc and python3-snappy are also not compatible with the version of pandas. -- Shengjing Zhu
Re: Updating python3-xlrd for pandas 1.5 compatibility
On Sat, Feb 25, 2023 at 2:33 AM Paul Gevers wrote: > pandas has a quite extensive autopkgtest, doesn't it > cover this use case? Apparently you knew this earlier, why do you bring > this up now? Seems a bit unfortunate when pandas updates the version. https://salsa.debian.org/science-team/pandas/-/blob/debian/1.5.3+dfsg-2/pandas/tests/io/excel/test_xlrd.py#L13 https://salsa.debian.org/science-team/pandas/-/blob/debian/1.5.3+dfsg-2/debian/tests/control#L51 A RC bug for python3-xlrd was missing when pandas updated to 1.4.3+dfsg-1. -- Shengjing Zhu
Re: DEB_BUILD_OPTIONS=nowerror
On Fri, Feb 24, 2023 at 2:26 PM Helmut Grohne wrote: > > Hi, > > I observe a pattern repeated at least twice and probably more often in > packages. > > * A package adds -Werror to the build. When a new toolchain version is >uploaded, it triggers a new warning and that makes the package FTBFS. > * A package runs shellcheck during build. When a new shellcheck is >uploaded, it triggers a new warning and makes the package FTBFS. > IMO, these are just linters. And shouldn't not run after the source is released. I'd like to propose the option name `nolint`. -- Shengjing Zhu
Re: icc-profiles_2.2_source.changes REJECTED
Hi, On Fri, Feb 24, 2023 at 7:38 AM Jonas Smedegaard wrote: > > What to do when a package is blocked from getting updated due to it > being itself? > > I have tried replying to FTPmasters as invited in the rejection message, > but have been met with silence. > > I have tried filing bug#1030961 but have so far seen no response on that > either. > > Will it make sense to reassing that bugreport to the technical > committee? Or to the release team? Or should I request removal of the > package, because security bugfixes (however unlikely for a package > containing purely static data files) is impossible? > > > - Jonas > > Quoting Debian FTP Masters (2023-02-09 04:19:39) > > > > icc-profiles source: lintian output: 'license-problem-md5sum-non-free-file > > ECI-RGB.V1.0.icc usual name is ECI-RGB.V1.0.icc. Does not allow > > modification See also https://packages.debian.org/sid/icc-profiles.', > > automatically rejected package. [snip] > > icc-profiles source: lintian output: > > 'source-only-upload-to-non-free-without-autobuild ', automatically rejected > > package. > > icc-profiles source: If you have a good reason, you may override this > > lintian tag. It's auto rejected. So I think it can be technically solved. For license-problem-md5sum-non-free-file, it's obviously a false positive from lintian. It should not emit such if the source is the non-free section. It should be reported as a bug for the lintian package. And you can submit patches as well, backport to the version that ftp-master server uses. For source-only-upload-to-non-free-without-autobuild, it's really a bug in your upload. You should fix it. -- Shengjing Zhu
Bug#981301: elvish: please document where you want tab completion directives installed
Hi, On Thu, Feb 23, 2023 at 3:18 AM Daniel Kahn Gillmor wrote: > > On Fri 2021-01-29 12:47:53 +0800, Shengjing Zhu wrote: > > > It doesn't support global completion files yet. Author just says he will > > consider this after 0.15. > > Hi there! elvish is now several versions past 0.15. any ideas where to > put tab completion files so that elvish can pick them up automatically? > There is indeed something new landed in recent versions. https://elv.sh/ref/command.html#module-search-directories It now supports searching global modules in /usr/share/elvish/lib. However as the directory name shows, it's not meant for autocompletion scripts. After discussion with upstream, I think it's better to keep the status quo. We can see if a more sensible place that upstream will use in next debian release cycle. -- Shengjing Zhu
Bug#865975: docker.io changes iptables default FORWARD policy to DROP, breaks VM and others
On Tue, Feb 21, 2023 at 5:03 PM Per Lundberg wrote: > > Regretfully, this bug is still active and it's trivial to reproduce with > this configuration: > > * apt-get install docker.io (ensure that the docker daemon is running > afterwards. Tested with 20.10.22+dfsg1-2 locally) > * apt-get install lxd (tested with 5.0.1-5) > > Then, "lxc launch ubuntu:22.04" (accepting the defaults for LXD > configuration). Networking will be broken inside the newly created LXD > container. > > The workaround for me is to run "sudo iptables -P FORWARD ACCEPT" after > bootup (and after Docker has started). But I agree with previous > comments; it's EXTREMELY BAD and unacceptable for a program like Docker > to misbehave like this. > > On the LXD side, this has been discussed and is a known issue: > > * > https://discuss.linuxcontainers.org/t/lxd-and-docker-firewall-redux-how-to-deal-with-forward-policy-set-to-drop/9953/9 > * > https://linuxcontainers.org/lxd/docs/master/howto/network_bridge_firewalld/#prevent-issues-with-lxd-and-docker > > (The suggestion given there is to insert firewall rules into the > DOCKER-USER chain.) > > I suggest we would consider patching the Docker package in Debian to > remove the FORWARD DROP nonsense until this has been properly resolved > upstream. We can't have programs that misbehave this badly in the > distribution, IMO. Please read message#91 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865975#91 and then think about it. If you still think there's a secure patch that we can apply, I'd like to review. -- Shengjing Zhu
Bug#1031637: ITP: roff -- Roff lets you write roff documents in Go
On Mon, Feb 20, 2023 at 1:38 AM Scarlett Moore wrote: > > > On 2/19/23 10:35, Shengjing Zhu wrote: > > On Mon, Feb 20, 2023 at 1:21 AM Scarlett Moore wrote: > >> Package: wnpp > >> Severity: wishlist > >> Owner: Scarlett Moore > >> X-Debbugs-Cc: debian-de...@lists.debian.org, sgmo...@debian.org > >> > >> * Package name: roff > > It doesn't sound quite right. roff is a file format. Does the package > > really need to be called `roff`? > > > >>Version : 0.1.0 > >>Upstream Author : Christian Muehlhaeuser > >> * URL : https://github.com/mueslix/roff > > This is 404. I assume you mean https://github.com/muesli/roff > yes > > > > Then the package name is really wrong. It's a Go library, the name > > should be golang-github-muesli-roff. > > Please read > > https://go-team.pages.debian.net/packaging.html#_naming_conventions_2 > > ok, new to go packaging. I used dh-make-golang and assumed it named it > correctly. My apologies. I think it's because the library contains an example which produces a binary. It will confuse dh-make-golang. So dh-make-golang has an option, you can use `dh-make-golang make -type library`. Besides, after dh-make-golang creating the template, you should adjust debian/rules with: ``` export DH_GOLANG_EXCLUDES := examples ``` This usage is documented at https://manpages.debian.org/bullseye/dh-golang/Debian::Debhelper::Buildsystem::golang.3pm.en.html#DH_GOLANG_EXCLUDES (Yeah, we know the manpage name is difficult to find..) -- Shengjing Zhu
Bug#1031637: ITP: roff -- Roff lets you write roff documents in Go
On Mon, Feb 20, 2023 at 1:38 AM Scarlett Moore wrote: > > > On 2/19/23 10:35, Shengjing Zhu wrote: > > On Mon, Feb 20, 2023 at 1:21 AM Scarlett Moore wrote: > >> Package: wnpp > >> Severity: wishlist > >> Owner: Scarlett Moore > >> X-Debbugs-Cc: debian-de...@lists.debian.org, sgmo...@debian.org > >> > >> * Package name: roff > > It doesn't sound quite right. roff is a file format. Does the package > > really need to be called `roff`? > > > >>Version : 0.1.0 > >>Upstream Author : Christian Muehlhaeuser > >> * URL : https://github.com/mueslix/roff > > This is 404. I assume you mean https://github.com/muesli/roff > yes > > > > Then the package name is really wrong. It's a Go library, the name > > should be golang-github-muesli-roff. > > Please read > > https://go-team.pages.debian.net/packaging.html#_naming_conventions_2 > > ok, new to go packaging. I used dh-make-golang and assumed it named it > correctly. My apologies. I think it's because the library contains an example which produces a binary. It will confuse dh-make-golang. So dh-make-golang has an option, you can use `dh-make-golang make -type library`. Besides, after dh-make-golang creating the template, you should adjust debian/rules with: ``` export DH_GOLANG_EXCLUDES := examples ``` This usage is documented at https://manpages.debian.org/bullseye/dh-golang/Debian::Debhelper::Buildsystem::golang.3pm.en.html#DH_GOLANG_EXCLUDES (Yeah, we know the manpage name is difficult to find..) -- Shengjing Zhu
Bug#1031637: ITP: roff -- Roff lets you write roff documents in Go
On Mon, Feb 20, 2023 at 1:21 AM Scarlett Moore wrote: > > Package: wnpp > Severity: wishlist > Owner: Scarlett Moore > X-Debbugs-Cc: debian-de...@lists.debian.org, sgmo...@debian.org > > * Package name: roff It doesn't sound quite right. roff is a file format. Does the package really need to be called `roff`? > Version : 0.1.0 > Upstream Author : Christian Muehlhaeuser > * URL : https://github.com/mueslix/roff This is 404. I assume you mean https://github.com/muesli/roff Then the package name is really wrong. It's a Go library, the name should be golang-github-muesli-roff. Please read https://go-team.pages.debian.net/packaging.html#_naming_conventions_2 -- Shengjing Zhu
Bug#1031637: ITP: roff -- Roff lets you write roff documents in Go
On Mon, Feb 20, 2023 at 1:21 AM Scarlett Moore wrote: > > Package: wnpp > Severity: wishlist > Owner: Scarlett Moore > X-Debbugs-Cc: debian-de...@lists.debian.org, sgmo...@debian.org > > * Package name: roff It doesn't sound quite right. roff is a file format. Does the package really need to be called `roff`? > Version : 0.1.0 > Upstream Author : Christian Muehlhaeuser > * URL : https://github.com/mueslix/roff This is 404. I assume you mean https://github.com/muesli/roff Then the package name is really wrong. It's a Go library, the name should be golang-github-muesli-roff. Please read https://go-team.pages.debian.net/packaging.html#_naming_conventions_2 -- Shengjing Zhu
Bug#1031630: bullseye-pu: package containerd/1.4.13~ds1-1~deb11u4
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: contain...@packages.debian.org, t...@security.debian.org,
z...@debian.org
Control: affects -1 + src:containerd
[ Reason ]
Backport patches for 2 CVE:
* CVE-2023-25153: OCI image importer memory exhaustion
* CVE-2023-25173: Supplementary groups are not set up properly
[ Impact ]
[ Tests ]
CVE-2023-25153 is simple fix without test.
CVE-2023-25173 is covered by some unit tests and I've tested
it on a Kubernetes cluster.
[ Risks ]
The patch for CVE-2023-25153 is simple and cherry-picked from upstream
1.5 branch directly. It should not be risky.
The patch for CVE-2023-25173 is difficult to backport (many conflicts
when apply patches from 1.5 branch).
So I have rewrite it based on the commits on 1.5 branch. Especially this
commit https://github.com/containerd/containerd/commit/a62c38bf.
The 1.4.x package doesn't include CRI integration tests so I have to test
it by hand on a real Kubernetes cluster. In upstream a62c38bf commit message,
they have shown the tests cases. So I use them to verify on Kubernetes.
With containerd/1.4.13~ds1-1~deb11u3, the log is
NAMESPACE NAMEREADY STATUS RESTARTS AGE
default test-group-add-1-group-add-1234 0/1 Error 014m
default test-no-option 0/1 Error 014m
default test-user-1234 0/1 Error 014m
default test-user-1234-1234 0/1 Error 014m
default test-user-1234-group-add-1234 0/1 Error 014m
The container output is like
# kubectl logs test-no-option
+ id
+ '[' 'uid=0(root) gid=0(root) groups=10(wheel)' '=' 'uid=0(root) gid=0(root)
groups=0(root),10(wheel)' ]
With containerd/1.4.13~ds1-1~deb11u4, the log is
NAMESPACE NAMEREADY STATUS RESTARTS AGE
default test-group-add-1-group-add-1234 0/1 Completed 0 4s
default test-no-option 0/1 Completed 0 4s
default test-user-1234 0/1 Completed 0 4s
default test-user-1234-1234 0/1 Completed 0 4s
default test-user-1234-group-add-1234 0/1 Completed 0 4s
The container output is like
# kubectl logs test-no-option
+ id
+ '[' 'uid=0(root) gid=0(root) groups=0(root),10(wheel)' '=' 'uid=0(root)
gid=0(root) groups=0(root),10(wheel)' ]
It has passed the upstream tests.
[ 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 (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
See attachment.
[ Other info ]
No
diff -Nru containerd-1.4.13~ds1/debian/changelog
containerd-1.4.13~ds1/debian/changelog
--- containerd-1.4.13~ds1/debian/changelog 2022-12-08 10:24:34.0
+0800
+++ containerd-1.4.13~ds1/debian/changelog 2023-02-17 23:11:26.0
+0800
@@ -1,3 +1,10 @@
+containerd (1.4.13~ds1-1~deb11u4) bullseye; urgency=medium
+
+ * CVE-2023-25153: OCI image importer memory exhaustion
+ * CVE-2023-25173: Supplementary groups are not set up properly
+
+ -- Shengjing Zhu Fri, 17 Feb 2023 23:11:26 +0800
+
containerd (1.4.13~ds1-1~deb11u3) bullseye; urgency=medium
* CVE-2022-23471: CRI plugin: Fix goroutine leak during Exec
diff -Nru containerd-1.4.13~ds1/debian/patches/0012-CVE-2023-25153.patch
containerd-1.4.13~ds1/debian/patches/0012-CVE-2023-25153.patch
--- containerd-1.4.13~ds1/debian/patches/0012-CVE-2023-25153.patch
1970-01-01 08:00:00.0 +0800
+++ containerd-1.4.13~ds1/debian/patches/0012-CVE-2023-25153.patch
2023-02-17 23:11:26.0 +0800
@@ -0,0 +1,41 @@
+From: Samuel Karp
+Date: Thu, 12 Jan 2023 18:06:41 -0800
+Subject: CVE-2023-25153
+
+Origin: backport, https://github.com/containerd/containerd/commit/959e1cf9
+---
+ images/archive/importer.go | 13 +++--
+ 1 file changed, 7 insertions(+), 6 deletions(-)
+
+diff --git a/images/archive/importer.go b/images/archive/importer.go
+index 2d04658..f24ab87 100644
+--- a/images/archive/importer.go
b/images/archive/importer.go
+@@ -24,7 +24,6 @@ import (
+ "encoding/json"
+ "fmt"
+ "io"
+- "io/ioutil"
+ "path"
+
+ "github.com/containerd/containerd/archive/compression"
+@@ -222,12 +221,14 @@ func ImportIndex(ctx context.Context, store
content.Store, reader io.Reader, opt
+ return writeManifest(ctx, store, idx, ocispec.MediaTypeImageIndex)
+ }
+
++const (
++ kib = 1024
++ mib = 1024 * kib
++ jsonLimit = 20 * mib
++)
++
+ func onUntarJSON(r io.Reader, j interface{}) error {
+- b, err := ioutil.ReadAll(r)
+- if err != nil {
+- return err
+- }
+- return json.Unmarshal(b, j)
++ return json.NewDecoder(io.Li
Bug#1031630: bullseye-pu: package containerd/1.4.13~ds1-1~deb11u4
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: contain...@packages.debian.org, t...@security.debian.org,
z...@debian.org
Control: affects -1 + src:containerd
[ Reason ]
Backport patches for 2 CVE:
* CVE-2023-25153: OCI image importer memory exhaustion
* CVE-2023-25173: Supplementary groups are not set up properly
[ Impact ]
[ Tests ]
CVE-2023-25153 is simple fix without test.
CVE-2023-25173 is covered by some unit tests and I've tested
it on a Kubernetes cluster.
[ Risks ]
The patch for CVE-2023-25153 is simple and cherry-picked from upstream
1.5 branch directly. It should not be risky.
The patch for CVE-2023-25173 is difficult to backport (many conflicts
when apply patches from 1.5 branch).
So I have rewrite it based on the commits on 1.5 branch. Especially this
commit https://github.com/containerd/containerd/commit/a62c38bf.
The 1.4.x package doesn't include CRI integration tests so I have to test
it by hand on a real Kubernetes cluster. In upstream a62c38bf commit message,
they have shown the tests cases. So I use them to verify on Kubernetes.
With containerd/1.4.13~ds1-1~deb11u3, the log is
NAMESPACE NAMEREADY STATUS RESTARTS AGE
default test-group-add-1-group-add-1234 0/1 Error 014m
default test-no-option 0/1 Error 014m
default test-user-1234 0/1 Error 014m
default test-user-1234-1234 0/1 Error 014m
default test-user-1234-group-add-1234 0/1 Error 014m
The container output is like
# kubectl logs test-no-option
+ id
+ '[' 'uid=0(root) gid=0(root) groups=10(wheel)' '=' 'uid=0(root) gid=0(root)
groups=0(root),10(wheel)' ]
With containerd/1.4.13~ds1-1~deb11u4, the log is
NAMESPACE NAMEREADY STATUS RESTARTS AGE
default test-group-add-1-group-add-1234 0/1 Completed 0 4s
default test-no-option 0/1 Completed 0 4s
default test-user-1234 0/1 Completed 0 4s
default test-user-1234-1234 0/1 Completed 0 4s
default test-user-1234-group-add-1234 0/1 Completed 0 4s
The container output is like
# kubectl logs test-no-option
+ id
+ '[' 'uid=0(root) gid=0(root) groups=0(root),10(wheel)' '=' 'uid=0(root)
gid=0(root) groups=0(root),10(wheel)' ]
It has passed the upstream tests.
[ 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 (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
See attachment.
[ Other info ]
No
diff -Nru containerd-1.4.13~ds1/debian/changelog
containerd-1.4.13~ds1/debian/changelog
--- containerd-1.4.13~ds1/debian/changelog 2022-12-08 10:24:34.0
+0800
+++ containerd-1.4.13~ds1/debian/changelog 2023-02-17 23:11:26.0
+0800
@@ -1,3 +1,10 @@
+containerd (1.4.13~ds1-1~deb11u4) bullseye; urgency=medium
+
+ * CVE-2023-25153: OCI image importer memory exhaustion
+ * CVE-2023-25173: Supplementary groups are not set up properly
+
+ -- Shengjing Zhu Fri, 17 Feb 2023 23:11:26 +0800
+
containerd (1.4.13~ds1-1~deb11u3) bullseye; urgency=medium
* CVE-2022-23471: CRI plugin: Fix goroutine leak during Exec
diff -Nru containerd-1.4.13~ds1/debian/patches/0012-CVE-2023-25153.patch
containerd-1.4.13~ds1/debian/patches/0012-CVE-2023-25153.patch
--- containerd-1.4.13~ds1/debian/patches/0012-CVE-2023-25153.patch
1970-01-01 08:00:00.0 +0800
+++ containerd-1.4.13~ds1/debian/patches/0012-CVE-2023-25153.patch
2023-02-17 23:11:26.0 +0800
@@ -0,0 +1,41 @@
+From: Samuel Karp
+Date: Thu, 12 Jan 2023 18:06:41 -0800
+Subject: CVE-2023-25153
+
+Origin: backport, https://github.com/containerd/containerd/commit/959e1cf9
+---
+ images/archive/importer.go | 13 +++--
+ 1 file changed, 7 insertions(+), 6 deletions(-)
+
+diff --git a/images/archive/importer.go b/images/archive/importer.go
+index 2d04658..f24ab87 100644
+--- a/images/archive/importer.go
b/images/archive/importer.go
+@@ -24,7 +24,6 @@ import (
+ "encoding/json"
+ "fmt"
+ "io"
+- "io/ioutil"
+ "path"
+
+ "github.com/containerd/containerd/archive/compression"
+@@ -222,12 +221,14 @@ func ImportIndex(ctx context.Context, store
content.Store, reader io.Reader, opt
+ return writeManifest(ctx, store, idx, ocispec.MediaTypeImageIndex)
+ }
+
++const (
++ kib = 1024
++ mib = 1024 * kib
++ jsonLimit = 20 * mib
++)
++
+ func onUntarJSON(r io.Reader, j interface{}) error {
+- b, err := ioutil.ReadAll(r)
+- if err != nil {
+- return err
+- }
+- return json.Unmarshal(b, j)
++ return json.NewDecoder(io.Li
Bug#1031388: icingaweb2-module-pdfexport: server software depending on chromium?
On Thu, 16 Feb 2023 12:45:20 +0100 David Kunz wrote: > > > The current version of icingaweb2-module-pdfexport depends on chromium. > All versions are like thes. > > > icingaweb2 is a web service. Depending on a graphical browser in a web > > server component is not at all reasonable. > I know, but upstream considers this to be the best possible way to solve > this problem. > > Now we can provide this package as it is or no package exist and all > packages that depends to it are unusable. You can demote chromium to Recommends. There are multiple benefits: + Users can use proprietary version of chrome from Google + Users can use snap/flatpak to install the latest chromium. + Users can use remote chromium as documented here: https://github.com/Icinga/icingaweb2-module-pdfexport/blob/master/doc/02-Installation.md#using-a-remote-chromechromium
Bug#1031388: icingaweb2-module-pdfexport: server software depending on chromium?
On Thu, 16 Feb 2023 12:45:20 +0100 David Kunz wrote: > > > The current version of icingaweb2-module-pdfexport depends on chromium. > All versions are like thes. > > > icingaweb2 is a web service. Depending on a graphical browser in a web > > server component is not at all reasonable. > I know, but upstream considers this to be the best possible way to solve > this problem. > > Now we can provide this package as it is or no package exist and all > packages that depends to it are unusable. You can demote chromium to Recommends. There are multiple benefits: + Users can use proprietary version of chrome from Google + Users can use snap/flatpak to install the latest chromium. + Users can use remote chromium as documented here: https://github.com/Icinga/icingaweb2-module-pdfexport/blob/master/doc/02-Installation.md#using-a-remote-chromechromium
Bug#1031408: unblock: containerd/1.6.18~ds1-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: contain...@packages.debian.org, publicsuf...@packages.debian.org, z...@debian.org Control: affects -1 + src:containerd src:golang-golang-x-net src:publicsuffix Please age package containerd [ Reason ] * New upstream version 1.6.18~ds1 + CVE-2023-25153: OCI image importer memory exhaustion + CVE-2023-25173: Supplementary groups are not set up properly * Install cni-bridge-fp to /usr/lib/cni in autopkgtest [ Impact ] Delay of security fix. [ Tests ] This package has integration tests in autopkgtest. Though there are known failures cri-integration (one of the integrations). But it's not regression. 1.6.17~ds1-1 has 5 failed test cases. I've fixed the tests scripts in 1.6.18~ds1-1, and it has only 1 failed test case now. [ Risks ] [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [ ] attach debdiff against the package in testing [ Other info ] To age containerd, the following packages need age as well. + golang-golang-x-net/1:0.7.0+dfsg-1 * New upstream version 0.7.0 + CVE-2022-41723: http2/hpack: avoid quadratic complexity in hpack decoding + publicsuffix/20230209.2326-1 * new upstream version
Bug#1031408: unblock: containerd/1.6.18~ds1-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: contain...@packages.debian.org, publicsuf...@packages.debian.org, z...@debian.org Control: affects -1 + src:containerd src:golang-golang-x-net src:publicsuffix Please age package containerd [ Reason ] * New upstream version 1.6.18~ds1 + CVE-2023-25153: OCI image importer memory exhaustion + CVE-2023-25173: Supplementary groups are not set up properly * Install cni-bridge-fp to /usr/lib/cni in autopkgtest [ Impact ] Delay of security fix. [ Tests ] This package has integration tests in autopkgtest. Though there are known failures cri-integration (one of the integrations). But it's not regression. 1.6.17~ds1-1 has 5 failed test cases. I've fixed the tests scripts in 1.6.18~ds1-1, and it has only 1 failed test case now. [ Risks ] [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [ ] attach debdiff against the package in testing [ Other info ] To age containerd, the following packages need age as well. + golang-golang-x-net/1:0.7.0+dfsg-1 * New upstream version 0.7.0 + CVE-2022-41723: http2/hpack: avoid quadratic complexity in hpack decoding + publicsuffix/20230209.2326-1 * new upstream version
Re: rust-*/librust-* arch:any vs. arch:all and cross-compilation support
Shengjing Zhu 于 2023年2月16日周四 09:16写道： > Sam Hartman 于 2023年2月16日周四 06:37写道： > >> However, adding a question to the mix, why does arch all work for go >> packages? >> Do they not care about cross compilation, or are concerns somehow >> different there? > > > Go doesn't work. I guess we started from the common sense that > arch-indepent files should be arch:all. Or at that time Multi-Arch is not > widely recognized. > I should say Go doesn't work when an arch:any (usually a C library) is involved. But well most Go programs are pure Go which are not affected by this all-any trap. (Sent from my mobile device)
Re: rust-*/librust-* arch:any vs. arch:all and cross-compilation support
Sam Hartman 于 2023年2月16日周四 06:37写道： > However, adding a question to the mix, why does arch all work for go > packages? > Do they not care about cross compilation, or are concerns somehow > different there? Go doesn't work. I guess we started from the common sense that arch-indepent files should be arch:all. Or at that time Multi-Arch is not widely recognized. (There is also a cross compile related patch in golang-defaults that haven't been merged yet for some years.) (Sent from my mobile device)
Bug#1031330: [pre-approval] unblock: golang-1.19/1.19.6-2
On Wed, Feb 15, 2023 at 9:23 PM Adrian Bunk wrote: > > And regarding make golang-go the first alternative, currently we have: > > + Build-Depends golang-any | golang-go | gccgo > > + golang-any Depends golang-go | gccgo-go > > Is there anything we can improve for aspcud resolver? > > The resolver is not to blame for a bug in the build dependencies. > > In unstable and experimental only the first alternative is considered, > therefore > Build-Depends: golang-go | ... > would instruct the resolver to install golang-go. > > Safest would be to not offer any alternatives in the build dependencies, > instead create a profile for bootstrapping golang-go from gccgo. I now created #1031351, which I think is the underlying problem. Let's keep discussion there and reduce the noise in this unblock request. -- Shengjing Zhu
Bug#1031330: [pre-approval] unblock: golang-1.19/1.19.6-2
On Wed, Feb 15, 2023 at 9:23 PM Adrian Bunk wrote: > > And regarding make golang-go the first alternative, currently we have: > > + Build-Depends golang-any | golang-go | gccgo > > + golang-any Depends golang-go | gccgo-go > > Is there anything we can improve for aspcud resolver? > > The resolver is not to blame for a bug in the build dependencies. > > In unstable and experimental only the first alternative is considered, > therefore > Build-Depends: golang-go | ... > would instruct the resolver to install golang-go. > > Safest would be to not offer any alternatives in the build dependencies, > instead create a profile for bootstrapping golang-go from gccgo. I now created #1031351, which I think is the underlying problem. Let's keep discussion there and reduce the noise in this unblock request. -- Shengjing Zhu
Bug#1031351: Make golang-any have determinate Depends
Package: golang-any Severity: normal X-Debbugs-Cc: z...@debian.org While reply https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031330#22 I realize we have similar problem when building Go programs in experimental and backports. The aspcud resolver for unknown reason that prefers gccgo-go on arch where golang-go is available. That causes unexpected build failures, especially annoying for backports. While it's good to keep packages buildable with gccgo, the reality is only golang-go is tested on sid. So we can't know the build failures in advance. So we should remove the alternative Depends in golang-any, to have a determinate result. I think we previously use "golang-go | gccgo-go" because it's easies to write debian/control file. Can we have different Depends for different arch? Can we reduce the duplication of arch list with golang-go?
Bug#1031330: [pre-approval] unblock: golang-1.19/1.19.6-2
On Wed, Feb 15, 2023 at 8:53 PM Shengjing Zhu wrote: > > On Wed, Feb 15, 2023 at 7:56 PM Adrian Bunk wrote: > > > > On Wed, Feb 15, 2023 at 11:58:54AM +0800, Shengjing Zhu wrote: > > >... > > > The package currently FTBFS on i386/experimental but it won't be problem > > > on > > > unstable. > > > The dep-resolver (aspcud) in experimental chooses gccgo to bootstrap, > > > which has a bug https://github.com/golang/go/issues/51850. > > > But on unstable the dep-resolver is apt, and will choose old golang-go to > > > bootstrap. > > >... > > > > I gave it back on the affected architectures with an extra-depends on > > golang-go, which confirmed that the package builds there. > > > > But relying on resolver behaviour is incredibly fragile, please make > > golang-go the only (or at least the first) alternative in the build > > dependencies. > > In theory gccgo should be able to bootstrap golang-go. > And we do use gccgo to build golang-go on ppc64, and haven't met any > problem so far. > The new affected arch is because of lack of exercise, so nobody is > aware of this. > Now they are tracked at #1031349. > And regarding make golang-go the first alternative, currently we have: + Build-Depends golang-any | golang-go | gccgo + golang-any Depends golang-go | gccgo-go Is there anything we can improve for aspcud resolver? -- Shengjing Zhu
Bug#1031330: [pre-approval] unblock: golang-1.19/1.19.6-2
On Wed, Feb 15, 2023 at 8:53 PM Shengjing Zhu wrote: > > On Wed, Feb 15, 2023 at 7:56 PM Adrian Bunk wrote: > > > > On Wed, Feb 15, 2023 at 11:58:54AM +0800, Shengjing Zhu wrote: > > >... > > > The package currently FTBFS on i386/experimental but it won't be problem > > > on > > > unstable. > > > The dep-resolver (aspcud) in experimental chooses gccgo to bootstrap, > > > which has a bug https://github.com/golang/go/issues/51850. > > > But on unstable the dep-resolver is apt, and will choose old golang-go to > > > bootstrap. > > >... > > > > I gave it back on the affected architectures with an extra-depends on > > golang-go, which confirmed that the package builds there. > > > > But relying on resolver behaviour is incredibly fragile, please make > > golang-go the only (or at least the first) alternative in the build > > dependencies. > > In theory gccgo should be able to bootstrap golang-go. > And we do use gccgo to build golang-go on ppc64, and haven't met any > problem so far. > The new affected arch is because of lack of exercise, so nobody is > aware of this. > Now they are tracked at #1031349. > And regarding make golang-go the first alternative, currently we have: + Build-Depends golang-any | golang-go | gccgo + golang-any Depends golang-go | gccgo-go Is there anything we can improve for aspcud resolver? -- Shengjing Zhu
Bug#1031330: [pre-approval] unblock: golang-1.19/1.19.6-2
On Wed, Feb 15, 2023 at 7:56 PM Adrian Bunk wrote: > > On Wed, Feb 15, 2023 at 11:58:54AM +0800, Shengjing Zhu wrote: > >... > > The package currently FTBFS on i386/experimental but it won't be problem on > > unstable. > > The dep-resolver (aspcud) in experimental chooses gccgo to bootstrap, > > which has a bug https://github.com/golang/go/issues/51850. > > But on unstable the dep-resolver is apt, and will choose old golang-go to > > bootstrap. > >... > > I gave it back on the affected architectures with an extra-depends on > golang-go, which confirmed that the package builds there. > > But relying on resolver behaviour is incredibly fragile, please make > golang-go the only (or at least the first) alternative in the build > dependencies. In theory gccgo should be able to bootstrap golang-go. And we do use gccgo to build golang-go on ppc64, and haven't met any problem so far. The new affected arch is because of lack of exercise, so nobody is aware of this. Now they are tracked at #1031349. -- Shengjing Zhu
Bug#1031330: [pre-approval] unblock: golang-1.19/1.19.6-2
On Wed, Feb 15, 2023 at 7:56 PM Adrian Bunk wrote: > > On Wed, Feb 15, 2023 at 11:58:54AM +0800, Shengjing Zhu wrote: > >... > > The package currently FTBFS on i386/experimental but it won't be problem on > > unstable. > > The dep-resolver (aspcud) in experimental chooses gccgo to bootstrap, > > which has a bug https://github.com/golang/go/issues/51850. > > But on unstable the dep-resolver is apt, and will choose old golang-go to > > bootstrap. > >... > > I gave it back on the affected architectures with an extra-depends on > golang-go, which confirmed that the package builds there. > > But relying on resolver behaviour is incredibly fragile, please make > golang-go the only (or at least the first) alternative in the build > dependencies. In theory gccgo should be able to bootstrap golang-go. And we do use gccgo to build golang-go on ppc64, and haven't met any problem so far. The new affected arch is because of lack of exercise, so nobody is aware of this. Now they are tracked at #1031349. -- Shengjing Zhu
Bug#1031349: gccgo fails to bootstrap golang-go on armel/armhf/i386/mips64el/mipsel
Source: golang-1.19 Severity: wishlist X-Debbugs-Cc: z...@debian.org https://buildd.debian.org/status/fetch.php?pkg=golang-1.19=armel=1.19.6-1=1676430951=0 https://buildd.debian.org/status/fetch.php?pkg=golang-1.19=armhf=1.19.6-1=1676431493=0 https://buildd.debian.org/status/fetch.php?pkg=golang-1.19=i386=1.19.6-1=1676430343=0 https://buildd.debian.org/status/fetch.php?pkg=golang-1.19=mips64el=1.19.6-1=1676447813=0 https://buildd.debian.org/status/fetch.php?pkg=golang-1.19=mipsel=1.19.6-1=1676447922=0
Bug#1031263: RM: golang-github-alangpierce-go-forceexport -- RoQA; Not working since Go1.17, upstream seems abandoned
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: golang-github-alangpierce-go-forceexp...@packages.debian.org, z...@debian.org Control: affects -1 + src:golang-github-alangpierce-go-forceexport It FTBFS for a long time. Last upstream commit is at 2016. It was introduced as Build-Depends of Syncthing, not needed anymore.
Bug#1030928: ITP: nerdctl -- nerdctl is a Docker-compatible CLI for containerd.
On Thu, Feb 9, 2023 at 8:03 PM Han Xu wrote: > > Package: wnpp > Severity: wishlist > Owner: Han Xu > X-Debbugs-Cc: debian-de...@lists.debian.org, suyanh...@gmail.com > > * Package name: nerdctl ... > The packages that nerdctl depends on all exist in Debian, such as containerd. This is not true. There are many build dependencies missing. And I know nerdctl continues exploding its build dependencies. This is yet another giant monster software. > Our team is packaging and maintaining this package. > -- Shengjing Zhu
Bug#1030928: ITP: nerdctl -- nerdctl is a Docker-compatible CLI for containerd.
On Thu, Feb 9, 2023 at 8:03 PM Han Xu wrote: > > Package: wnpp > Severity: wishlist > Owner: Han Xu > X-Debbugs-Cc: debian-de...@lists.debian.org, suyanh...@gmail.com > > * Package name: nerdctl ... > The packages that nerdctl depends on all exist in Debian, such as containerd. This is not true. There are many build dependencies missing. And I know nerdctl continues exploding its build dependencies. This is yet another giant monster software. > Our team is packaging and maintaining this package. > -- Shengjing Zhu
Bug#1030862: RM: golang-1.18 -- RoQA; EOL
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.18 After the release go1.20 (2023-02-01), go1.18 is end of life.
Bug#1028841: marked as pending in gopacket
Control: tag -1 pending Hello, Bug #1028841 in gopacket reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/go-team/packages/gopacket/-/commit/69d0160931702639bbda0620316d815ea9fa7ca5 Add patch to skip comparing libpcap output in TestBPFInstruction Closes: #1028841 (this message was generated automatically) -- Greetings https://bugs.debian.org/1028841
Bug#1030809: RM: golang-github-willf-bitset -- ROM; duplicated with golang-github-bits-and-blooms-bitset
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: golang-github-willf-bit...@packages.debian.org, z...@debian.org Control: affects -1 + src:golang-github-willf-bitset These two packages are same source. https://github.com/willf/bitset is 302 to https://github.com/bits-and-blooms/bitset
Bug#1030706: sbuild should not purge packages for autopkgtest-virt-server=docker
Package: sbuild Version: 0.85.0 Severity: minor X-Debbugs-Cc: z...@debian.org I'm exploring to build package with autopkgtest-virt-server=docker. I find sbuild by default will purge packages after build. It should like schroot, detect that the mode is cloned chroot, and skip purging packages. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.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 Versions of packages sbuild depends on: ii adduser 3.130 ii libsbuild-perl 0.85.0 ii perl5.36.0-7 Versions of packages sbuild recommends: ii autopkgtest 5.28 pn debootstrap pn schroot ii uidmap 1:4.13+dfsg1-1 Versions of packages sbuild suggests: pn deborphan ii e2fsprogs 1.46.6-1 ii kmod 30+20221128-1 ii wget 1.21.3-1+b2 -- no debconf information
Bug#1030705: debug shell doesn't work with autopkgtest-virt-server=docker
Package: sbuild Version: 0.85.0 Severity: normal X-Debbugs-Cc: z...@debian.org I'm exploring to build package with autopkgtest-virt-server=docker. The following combination fails for me. gbp buildpackage --git-builder='sbuild --chroot-mode=autopkgtest --autopkgtest-virt-server=docker --autopkgtest-virt-server-opt=autopkgtest/debian:sid --purge-deps=never --anything-failed-commands=%s' ``` +--+ | Generic Build Failed Commands| +--+ bash -i /dev/tty 2>/dev/tty -- /bin/sh: 1: cannot open /dev/tty: No such device or address E: Command 'bash -i /dev/tty 2>/dev/tty' failed to run. Finished processing commands. E: Failed to execute build-failed-commands ``` The image is created with `autopkgtest-build-docker --image debian:sid` -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.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 Versions of packages sbuild depends on: ii adduser 3.130 ii libsbuild-perl 0.85.0 ii perl5.36.0-7 Versions of packages sbuild recommends: ii autopkgtest 5.28 pn debootstrap pn schroot ii uidmap 1:4.13+dfsg1-1 Versions of packages sbuild suggests: pn deborphan ii e2fsprogs 1.46.6-1 ii kmod 30+20221128-1 ii wget 1.21.3-1+b2 -- no debconf information
Bug#1030704: extra-package doesn't work with autopkgtest-virt-server=docker
Package: sbuild Version: 0.85.0 Severity: normal X-Debbugs-Cc: z...@debian.org I'm exploring to build package with autopkgtest-virt-server=docker. The following combination fails for me. gbp buildpackage --git-builder='sbuild --chroot-mode=autopkgtest --autopkgtest-virt-server=docker --autopkgtest-virt-server-opt=autopkgtest/debian:sid --purge-deps=never --extra-package=/home/zsj/Workspaces/debian/package/pkg-go/build-area/ --anything-failed-commands="sleep infinity"' I get ``` +--+ | Update chroot| +--+ Get:1 file:/build/golang-github-coredhcp-coredhcp-xIXI4Z/resolver-dcoFh4/apt_archive ./ InRelease Ign:1 file:/build/golang-github-coredhcp-coredhcp-xIXI4Z/resolver-dcoFh4/apt_archive ./ InRelease Get:2 file:/build/golang-github-coredhcp-coredhcp-xIXI4Z/resolver-dcoFh4/apt_archive ./ Release [603 B] Get:2 file:/build/golang-github-coredhcp-coredhcp-xIXI4Z/resolver-dcoFh4/apt_archive ./ Release [603 B] Get:3 file:/build/golang-github-coredhcp-coredhcp-xIXI4Z/resolver-dcoFh4/apt_archive ./ Release.gpg Ign:3 file:/build/golang-github-coredhcp-coredhcp-xIXI4Z/resolver-dcoFh4/apt_archive ./ Release.gpg Get:4 file:/build/golang-github-coredhcp-coredhcp-xIXI4Z/resolver-dcoFh4/apt_archive ./ Packages [999 B] Err:4 file:/build/golang-github-coredhcp-coredhcp-xIXI4Z/resolver-dcoFh4/apt_archive ./ Packages Could not open file /var/lib/apt/lists/partial/_build_golang-github-coredhcp-coredhcp-xIXI4Z_resolver-dcoFh4_apt%5farchive_._Packages - open (13: Permission denied) ... Fetched 440 kB in 2s (289 kB/s) Reading package lists... E: Failed to fetch store:/var/lib/apt/lists/partial/_build_golang-github-coredhcp-coredhcp-xIXI4Z_resolver-dcoFh4_apt%5farchive_._Packages Could not open file /var/lib/apt/lists/partial/_build_golang-github-coredhcp-coredhcp-xIXI4Z_resolver-dcoFh4_apt%5farchive_._Packages - open (13: Permission denied) E: Some index files failed to download. They have been ignored, or old ones used instead. ``` Then I exec to the container, I find root@b431ad0334a7:/# ls -l total 68 drwxrwsr-- 3 sbuild sbuild 4096 Feb 6 16:01 build root@b431ad0334a7:/# ls -l build/ drwxrwx--- 4 zsj sbuild 4096 Feb 6 16:01 golang-github-coredhcp-coredhcp-xIXI4Z These directories doesn't have read permission for all users. After I change the permission, apt succeeds. # chmod a+rx -R build/ # apt update ... All packages are up to date. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.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 Versions of packages sbuild depends on: ii adduser 3.130 ii libsbuild-perl 0.85.0 ii perl5.36.0-7 Versions of packages sbuild recommends: ii autopkgtest 5.28 pn debootstrap pn schroot ii uidmap 1:4.13+dfsg1-1 Versions of packages sbuild suggests: pn deborphan ii e2fsprogs 1.46.6-1 ii kmod 30+20221128-1 ii wget 1.21.3-1+b2 -- no debconf information
Bug#1030365: Doesn't work with qemu 7.2
Package: lxd Version: 5.0.2-2 Severity: normal X-Debbugs-Cc: z...@debian.org To launch vm with lxd, I get ``` $ lxc launch images:debian/sid debian-sid-vm --vm Creating debian-sid-vm Starting debian-sid-vm Error: Failed setting up device via monitor: Failed setting up device "eth0": Failed adding NIC netdev: Monitor is disconnected Try `lxc info --show-log local:debian-sid-vm` for more info ``` I find https://discuss.linuxcontainers.org/t/failed-adding-nic-netdev-monitor-is-disconnected/15946 it suggests a qemu patch in https://www.mail-archive.com/qemu-devel@nongnu.org/msg924611.html After I applied that, it just turns the crash to an error. So still not working. ``` $ lxc launch images:debian/sid debian-sid-vm --vm Creating debian-sid-vm Starting debian-sid-vm Error: Failed setting up device via monitor: Failed setting up device "eth0": Failed adding NIC netdev: Device 'lxd_eth0' could not be initialized ``` -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.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 Versions of packages lxd depends on: ii adduser 3.130 ii attr 1:2.5.1-4 ii ca-certificates 20211016 ii init-system-helpers 1.65.2 ii libacl1 2.3.1-3 ii libc62.36-8 ii libcap2 1:2.66-3 ii libdqlite0 1.11.1-1 ii libgcc-s112.2.0-14 ii liblxc-common1:5.0.2-1 ii liblxc1 1:5.0.2-1 ii libsqlite3-0 3.40.1-1 ii libudev1 252.4-2 ii lxcfs5.0.3-1 ii lxd-client 5.0.2-2 ii rsync3.2.7-1 ii squashfs-tools 1:4.5.1-1 ii uidmap 1:4.13+dfsg1-1 ii xz-utils 5.4.1-0.0 Versions of packages lxd recommends: ii apparmor 3.0.8-2+b1 ii dnsmasq-base [dnsmasq-base] 2.88-1 ii lxd-agent5.0.2-2 Versions of packages lxd suggests: pn btrfs-progs pn ceph-common ii gdisk 1.0.9-2.1 pn lvm2 pn lxd-tools pn zfsutils-linux -- no debconf information
Bug#1030158: marked as pending in golang-github-masterminds-sprig
Control: tag -1 pending Hello, Bug #1030158 in golang-github-masterminds-sprig reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/go-team/packages/golang-github-masterminds-sprig/-/commit/2a26f5ac959e605898a958a6bad64ebf8fdec837 Fix bad version in Breaks+Replaces (Closes: #1030158) (this message was generated automatically) -- Greetings https://bugs.debian.org/1030158
Bug#1029284: marked as pending in golang-github-rjeczalik-notify
Control: tag -1 pending Hello, Bug #1029284 in golang-github-rjeczalik-notify reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/go-team/packages/golang-github-rjeczalik-notify/-/commit/0d04ae0e0e0c138dd2089c0d356690ec14d15c1f Skip flaky TestRecreated (Closes: #1029284) (this message was generated automatically) -- Greetings https://bugs.debian.org/1029284
Bug#1029284: marked as done (golang-github-rjeczalik-notify FTBFS: FAIL: TestRecreated)
Control: reopen -1 On Sat, Jan 21, 2023 at 5:33 PM Debian Bug Tracking System wrote: > From: Sascha Steinbiss > To: 1029284-d...@bugs.debian.org > Cc: > Bcc: > Date: Sat, 21 Jan 2023 10:21:53 +0100 > Subject: Re: [pkg-go] Bug#1029284: golang-github-rjeczalik-notify FTBFS: > Hi, > > > https://buildd.debian.org/status/fetch.php?pkg=golang-github-rjeczalik-notify=all=0.9.3-1=1674231621=0 > > > > ... > > --- FAIL: TestRecreated (5.00s) > > ... > > FAIL > > FAIL github.com/rjeczalik/notify 20.037s > > FAIL > > dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 4 > > github.com/rjeczalik/notify returned exit code 1 > > make: *** [debian/rules:6: binary-indep] Error 25 > > Unfortunately, I could not reproduce this failure locally. The fact that > the timeout (5s) in the test is reached may have had to do with > different disk performance between the buildd and my laptop, since this > test is a bit IO-dependent. > > I have increased the timeout to 30s in my latest upload and now the test > passes. Closing this for now. > Still having chances to fail https://tests.reproducible-builds.org/debian/history/golang-github-rjeczalik-notify.html Since this package already skip one unreliable test previously, I'll update it to skip this one. -- Shengjing Zhu
Bug#1029284: marked as done (golang-github-rjeczalik-notify FTBFS: FAIL: TestRecreated)
Control: reopen -1 On Sat, Jan 21, 2023 at 5:33 PM Debian Bug Tracking System wrote: > From: Sascha Steinbiss > To: 1029284-d...@bugs.debian.org > Cc: > Bcc: > Date: Sat, 21 Jan 2023 10:21:53 +0100 > Subject: Re: [pkg-go] Bug#1029284: golang-github-rjeczalik-notify FTBFS: > Hi, > > > https://buildd.debian.org/status/fetch.php?pkg=golang-github-rjeczalik-notify=all=0.9.3-1=1674231621=0 > > > > ... > > --- FAIL: TestRecreated (5.00s) > > ... > > FAIL > > FAIL github.com/rjeczalik/notify 20.037s > > FAIL > > dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 4 > > github.com/rjeczalik/notify returned exit code 1 > > make: *** [debian/rules:6: binary-indep] Error 25 > > Unfortunately, I could not reproduce this failure locally. The fact that > the timeout (5s) in the test is reached may have had to do with > different disk performance between the buildd and my laptop, since this > test is a bit IO-dependent. > > I have increased the timeout to 30s in my latest upload and now the test > passes. Closing this for now. > Still having chances to fail https://tests.reproducible-builds.org/debian/history/golang-github-rjeczalik-notify.html Since this package already skip one unreliable test previously, I'll update it to skip this one. -- Shengjing Zhu
[pkg-go] Bug#1029284: marked as done (golang-github-rjeczalik-notify FTBFS: FAIL: TestRecreated)
Control: reopen -1 On Sat, Jan 21, 2023 at 5:33 PM Debian Bug Tracking System wrote: > From: Sascha Steinbiss > To: 1029284-d...@bugs.debian.org > Cc: > Bcc: > Date: Sat, 21 Jan 2023 10:21:53 +0100 > Subject: Re: [pkg-go] Bug#1029284: golang-github-rjeczalik-notify FTBFS: > Hi, > > > https://buildd.debian.org/status/fetch.php?pkg=golang-github-rjeczalik-notify=all=0.9.3-1=1674231621=0 > > > > ... > > --- FAIL: TestRecreated (5.00s) > > ... > > FAIL > > FAIL github.com/rjeczalik/notify 20.037s > > FAIL > > dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 4 > > github.com/rjeczalik/notify returned exit code 1 > > make: *** [debian/rules:6: binary-indep] Error 25 > > Unfortunately, I could not reproduce this failure locally. The fact that > the timeout (5s) in the test is reached may have had to do with > different disk performance between the buildd and my laptop, since this > test is a bit IO-dependent. > > I have increased the timeout to 30s in my latest upload and now the test > passes. Closing this for now. > Still having chances to fail https://tests.reproducible-builds.org/debian/history/golang-github-rjeczalik-notify.html Since this package already skip one unreliable test previously, I'll update it to skip this one. -- Shengjing Zhu ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
Bug#1017276: closing 1017276
close 1017276 thanks
Re: Please, minimize your build chroots
On Sat, Jan 28, 2023 at 9:29 PM Johannes Schauer Marin Rodrigues wrote: > To me it seems that we nearly are already at (2). The debootstrap bug #837060 > has a working patch and mmdebstrap exists that can do what is needed today. > Santiago did an archive rebuild to make sure our source package compile in a > chroot without Priority:required. > > Why do people call just accepting that Priority:required packages have to be > part of the buildd chroot the easier solution? We just need to fix debootstrap > bug #837060 and we are done, no? > Yes, please fix debootstrap or anything else first, and ensure buildd uses the fixed version. If you can't convince the buildd to follow the policy, why should the individual package maintainers? -- Shengjing Zhu
Bug#991462: Please update etcd to 3.5.5
On Fri, Jan 27, 2023 at 6:45 PM Dominik George wrote: > > Hi Thomas, Shengjing, et al, > > I am currently investigating if, and how, we could get etcd 3.5.7 into > Debian bookworm. It is already very short before the freeze, but yet… > let's at least discuss it. > > It looks like Shengjing is working on the package, but recently uploaded > 3.4.23. Shengjing, can you provide an update on your plans for bookworm? > I have tried my best to bring 3.4 to bookworm. I don't plan to do 3.5 in the near future. > The Git repository has a version 3.5.5 which according to the changelog > should have been uploaded to experimental, where I cannot find it. Thomas, > do you remember where this version went? > Thomas uploaded twice 3.5. But it was never built successfully. So it ends up being crufted by ftp-master. (You can search the log in https://ftp-master.debian.org/removals-2022.txt) > COncerning the reverse dependencies of golang-etcd-server-dev, are there > any known incompatibilities that would prevent a move to etcd 3.5.5? > You can use ratt[1] to check. That's the de-facto tool for the go team to check compatibility. If you want to do the 3.5 job, please be aware that etcd upstream doesn't support (or test) upgrading from 3.3 to 3.5 directly. I've addressed this to Thomas on IRC but been ignored. [1] https://tracker.debian.org/ratt -- Shengjing Zhu
Bug#1004534: Please promote version 1.38.0-1 to unstable
On Mon, Jan 23, 2023 at 4:12 AM Thomas Uhle wrote: > > Dear maintainers of the Debian Go Packaging Team, > > I would like to second Eric's wish to upload the version in experimental > (or perhaps a newer one) to unstable too, so that it can make its way to > bookworm before the freeze. Or is there any reason (that of course I > don't know) why it has to be a version like 1.33.3 instead? > It's too late. By bumping to 1.33.3 already takes a lot of time for me. Please be aware that a library like grpc-go is very essential in the Go ecosystem. Updating the version not only means just packaging the new version. You need to take care of the reverse dependencies. I'm not holding others to update the version. But no one shows the plan to ensure a smooth transition. -- Shengjing Zhu
Bug#1029416: delve: FTBFS in bookworm (undeclared build-dependency on tzdata)
On Mon, Jan 23, 2023 at 12:52 AM Santiago Vila wrote: > > El 22/1/23 a las 17:40, Shengjing Zhu escribió: > > The failure in the log doesn't look like tzdata related. > > Certainly it does not look tzdata related, but I believe it > is tzdata related because once I installed tzdata in the chroot > to test, it built fine. OK, I read the code and it's indeed related to tzdata. Just the error message is confusing. -- Shengjing Zhu
Bug#1029416: delve: FTBFS in bookworm (undeclared build-dependency on tzdata)
On Mon, Jan 23, 2023 at 12:52 AM Santiago Vila wrote: > > El 22/1/23 a las 17:40, Shengjing Zhu escribió: > > The failure in the log doesn't look like tzdata related. > > Certainly it does not look tzdata related, but I believe it > is tzdata related because once I installed tzdata in the chroot > to test, it built fine. OK, I read the code and it's indeed related to tzdata. Just the error message is confusing. -- Shengjing Zhu
Bug#1029416: delve: FTBFS in bookworm (undeclared build-dependency on tzdata)
Control: tags -1 -1 patch Control: retitle -1 delve: FTBFS: could not find symbol value On Mon, Jan 23, 2023 at 12:03 AM Santiago Vila wrote: > > Package: src:delve > Version: 1.20.0-1 > Severity: serious > Tags: ftbfs patch > > Dear maintainer: > > During a rebuild of all packages in bookworm, your package failed to build: > The failure in the log doesn't look like tzdata related. Could you share your full sbuild/pbuilder/etc log.
Bug#1029416: delve: FTBFS in bookworm (undeclared build-dependency on tzdata)
Control: tags -1 -1 patch Control: retitle -1 delve: FTBFS: could not find symbol value On Mon, Jan 23, 2023 at 12:03 AM Santiago Vila wrote: > > Package: src:delve > Version: 1.20.0-1 > Severity: serious > Tags: ftbfs patch > > Dear maintainer: > > During a rebuild of all packages in bookworm, your package failed to build: > The failure in the log doesn't look like tzdata related. Could you share your full sbuild/pbuilder/etc log.
Bug#1028452: unblock: golang-1.19/1.19.5-1
On Thu, Jan 19, 2023 at 6:01 PM Sebastiaan Couwenberg wrote: > > On 1/19/23 10:26, Shengjing Zhu wrote: > > On Thu, Jan 19, 2023 at 4:55 PM Paul Gevers wrote: > >>> The history record for golang point release doesn't show regressions. > >> > >> That's good, are you talking about point release in general, or releases > >> to stable? > > > > Missed this one. I'm talking about the upstream point release. We > > haven't met regression so far when we update golang-1.x packages in > > unstable. > > I remember 1.18.4 introducing a regression that broke icingadb: > > https://bugs.debian.org/1015088 > Oh! you're right. I do forget this. However it happens when people are too eager to use "generic" in Go, when it's said by upstream that "generic" is not stable in Go1.18. But yeah it's still breakage in point release. So upstream decides[1] not fixing any "generic" bugs in later Go1.18 point release. [1] https://github.com/golang/go/issues/53852#issuecomment-1184912669 -- Shengjing Zhu
Bug#1028452: unblock: golang-1.19/1.19.5-1
On Thu, Jan 19, 2023 at 6:01 PM Sebastiaan Couwenberg wrote: > > On 1/19/23 10:26, Shengjing Zhu wrote: > > On Thu, Jan 19, 2023 at 4:55 PM Paul Gevers wrote: > >>> The history record for golang point release doesn't show regressions. > >> > >> That's good, are you talking about point release in general, or releases > >> to stable? > > > > Missed this one. I'm talking about the upstream point release. We > > haven't met regression so far when we update golang-1.x packages in > > unstable. > > I remember 1.18.4 introducing a regression that broke icingadb: > > https://bugs.debian.org/1015088 > Oh! you're right. I do forget this. However it happens when people are too eager to use "generic" in Go, when it's said by upstream that "generic" is not stable in Go1.18. But yeah it's still breakage in point release. So upstream decides[1] not fixing any "generic" bugs in later Go1.18 point release. [1] https://github.com/golang/go/issues/53852#issuecomment-1184912669 -- Shengjing Zhu
Bug#1028452: unblock: golang-1.19/1.19.5-1
On Thu, Jan 19, 2023 at 4:55 PM Paul Gevers wrote: > > The history record for golang point release doesn't show regressions. > > That's good, are you talking about point release in general, or releases > to stable? Missed this one. I'm talking about the upstream point release. We haven't met regression so far when we update golang-1.x packages in unstable. -- Shengjing Zhu
Bug#1028452: unblock: golang-1.19/1.19.5-1
On Thu, Jan 19, 2023 at 4:55 PM Paul Gevers wrote: > > The history record for golang point release doesn't show regressions. > > That's good, are you talking about point release in general, or releases > to stable? Missed this one. I'm talking about the upstream point release. We haven't met regression so far when we update golang-1.x packages in unstable. -- Shengjing Zhu
Bug#1028452: unblock: golang-1.19/1.19.5-1
On Thu, Jan 19, 2023 at 4:55 PM Paul Gevers wrote: > > Dear Shengjing, > > On 11-01-2023 09:32, Shengjing Zhu wrote: > > This is a point release for golang 1.19 which happens today. > > Where can I find the upstream policy on point release updates? Or, if > not documented in one place, can you describe it? Is 1.19 a bug-fix only > branch already, or are new feature appearing in point release updates > too? In other words, help us assess the risk. > It's documented at https://go.dev/doc/devel/release#policy Yes, only bug fix. Usually there are only a few commits in each point release. > > [ Impact ] > > > > If we can be closer to upstream latest release, it will be easier to > > backport > > security patch for bookworm. > > That holds for every package, but we're now frozen, so we need to balance. > > > The history record for golang point release doesn't show regressions. > > That's good, are you talking about point release in general, or releases > to stable? For security updates in Debian stable releases, have you also > been uploading new point releases, or did you pick patches every time? > For bullseye, I uploaded the last point release of Go1.15. See https://tracker.debian.org/news/1284112/accepted-golang-115-11515-1deb11u1-source-into-proposed-updates-stable-new-proposed-updates/ It's a bit sad that upstream support is very short, which is 1 year for a major version. For Go1.19, it will EOL on 2023 Aug, which is very close to bookworm release. So I'll try to upload the last point release of Go1.19 in the 12.1 or 12.2 cycle. After that we would only backport security patches back. -- Shengjing Zhu
Bug#1028452: unblock: golang-1.19/1.19.5-1
On Thu, Jan 19, 2023 at 4:55 PM Paul Gevers wrote: > > Dear Shengjing, > > On 11-01-2023 09:32, Shengjing Zhu wrote: > > This is a point release for golang 1.19 which happens today. > > Where can I find the upstream policy on point release updates? Or, if > not documented in one place, can you describe it? Is 1.19 a bug-fix only > branch already, or are new feature appearing in point release updates > too? In other words, help us assess the risk. > It's documented at https://go.dev/doc/devel/release#policy Yes, only bug fix. Usually there are only a few commits in each point release. > > [ Impact ] > > > > If we can be closer to upstream latest release, it will be easier to > > backport > > security patch for bookworm. > > That holds for every package, but we're now frozen, so we need to balance. > > > The history record for golang point release doesn't show regressions. > > That's good, are you talking about point release in general, or releases > to stable? For security updates in Debian stable releases, have you also > been uploading new point releases, or did you pick patches every time? > For bullseye, I uploaded the last point release of Go1.15. See https://tracker.debian.org/news/1284112/accepted-golang-115-11515-1deb11u1-source-into-proposed-updates-stable-new-proposed-updates/ It's a bit sad that upstream support is very short, which is 1 year for a major version. For Go1.19, it will EOL on 2023 Aug, which is very close to bookworm release. So I'll try to upload the last point release of Go1.19 in the 12.1 or 12.2 cycle. After that we would only backport security patches back. -- Shengjing Zhu
Bug#1028452: unblock: golang-1.19/1.19.5-1
Control: reopen -1 Control: retitle -1 [pre-approval] unblock: golang-1.19/1.19.5-1 Hi, On Thu, Jan 19, 2023 at 3:45 AM Debian Bug Tracking System > On Thu, 12 Jan 2023 16:28:51 +0100 Paul Gevers wrote: > > But golang-1.19 is in sync between unstable and testing. > > Closing. > > Paul Sorry not to make it clear. It's a pre-approval request. -- Shengjing Zhu
Bug#1028452: unblock: golang-1.19/1.19.5-1
Control: reopen -1 Control: retitle -1 [pre-approval] unblock: golang-1.19/1.19.5-1 Hi, On Thu, Jan 19, 2023 at 3:45 AM Debian Bug Tracking System > On Thu, 12 Jan 2023 16:28:51 +0100 Paul Gevers wrote: > > But golang-1.19 is in sync between unstable and testing. > > Closing. > > Paul Sorry not to make it clear. It's a pre-approval request. -- Shengjing Zhu
Re: cri-o: new package in debian, need sponsor
On Mon, Jan 16, 2023 at 2:13 PM Shengjing Zhu wrote: > > On Mon, Jan 16, 2023 at 1:54 AM Alexey Lukyachuk wrote: > > > > Ho everyone! > > I have added new package cri-o to debian: > > https://mentors.debian.net/package/cri-o/ > > > > It's written in Go-Lang, so, it may be interested in your group. > > Also, I would like to ask the sponsor (mentor) for this package. > > > > Hope package will be useful > > > > Could you follow the instruction at > https://go-team.pages.debian.net/packaging.html and get started with > the dh-make-golang tool? > > I've looked at the package carefully Sorry, typo.. I mean I haven't... -- Shengjing Zhu
Re: cri-o: new package in debian, need sponsor
On Mon, Jan 16, 2023 at 1:54 AM Alexey Lukyachuk wrote: > > Ho everyone! > I have added new package cri-o to debian: > https://mentors.debian.net/package/cri-o/ > > It's written in Go-Lang, so, it may be interested in your group. > Also, I would like to ask the sponsor (mentor) for this package. > > Hope package will be useful > Could you follow the instruction at https://go-team.pages.debian.net/packaging.html and get started with the dh-make-golang tool? I've looked at the package carefully, but I find it doesn't follow the practice so I just stopped. One red flag is that you keep all the vendor copies. -- Shengjing Zhu
Re: lintian error: shared-library-lacks-prerequisites
On Sat, Jan 14, 2023 at 9:48 PM Peymaneh wrote: > > Hi, > > I have a question regarding the static linking of Go programs: > > I added -buildmode=pie to the compiler flags for Caddy[1] for additional > hardening. lintian now complains: > > > caddy: shared-library-lacks-prerequisites [usr/bin/caddy] > > The listed shared library doesn't include information about the other > > libraries against which it was linked. > > > > More specifically, "ldd foo.so" should report such other libraries. In your > > case, it reports "statically linked". > > > > The fix is to specify the libraries. One way to do so is to add something > > like "-lc" to the command-line options for "ld". > > I am not sure what to think of this: > > First, Caddy is not a shared library even and, as any other Go > executables, is usually statically linked. > > For amd64 the Go compiler uses internal linking and > > % objdump -p $caddy-binary-armhf | grep NEEDED > % > > is empty, but this is just as is should be. > > For some other platforms -buildmode=pie requires building with an > external linker, and the Caddy binary built for those correctly includes > this information: > > % objdump -p $caddy-binary-armhf | grep NEEDED >NEEDED libc.so.6 > > it seems to me this lintian warning is incorrect. Would it be sensible > to overwrite it? I am inclined to lintian this time. The binary is rather odd. It's statically linked, but the interpreter is set as well. The result comes from CGO_ENABLED=0 and -buildmode=pie. I'm not sure if these options are sensible to use together. But why do you want CGO_ENABLED=0? We should avoid this in Debian packaging. Shared binary is much preferred for distribution packages. Generally speaking, I prefer not hacking build flags in individual packages. This is the job of dh-golang. -- Shengjing Zhu
[PATCH] Dpkg::Vendor::Ubuntu: Respect options env when override features
It's bit unfortunate that I've to duplicate Dpkg::BuildOptions
parsing here.
LP: #2002582
---
scripts/Dpkg/Vendor/Ubuntu.pm | 23 ++-
scripts/t/Dpkg_BuildFlags_Ubuntu.t | 28 +++-
2 files changed, 49 insertions(+), 2 deletions(-)
diff --git a/scripts/Dpkg/Vendor/Ubuntu.pm b/scripts/Dpkg/Vendor/Ubuntu.pm
index df42580e2..720475e94 100644
--- a/scripts/Dpkg/Vendor/Ubuntu.pm
+++ b/scripts/Dpkg/Vendor/Ubuntu.pm
@@ -114,11 +114,32 @@ sub set_build_features {
$self->SUPER::set_build_features($flags);
+my %default_feature = (
+optimize => {
+lto => 0,
+},
+);
+
+
require Dpkg::Arch;
my $arch = Dpkg::Arch::get_host_arch();
if (any { $_ eq $arch } qw(amd64 arm64 ppc64el s390x)) {
-$flags->set_feature('optimize', 'lto', 1);
+$default_feature{optimize}{lto} = 1;
+}
+
+my $opts_build = Dpkg::BuildOptions->new(envvar => 'DEB_BUILD_OPTIONS');
+my $opts_maint = Dpkg::BuildOptions->new(envvar =>
'DEB_BUILD_MAINT_OPTIONS');
+
+foreach my $area (sort keys %default_feature) {
+$opts_build->parse_features($area, $default_feature{$area});
+$opts_maint->parse_features($area, $default_feature{$area});
+}
+
+foreach my $area (sort keys %default_feature) {
+while (my ($feature, $enabled) = each %{$default_feature{$area}}) {
+$flags->set_feature($area, $feature, $enabled);
+}
}
if ($arch eq 'ppc64el' && $flags->get_option_value('optimize-level') != 0)
{
diff --git a/scripts/t/Dpkg_BuildFlags_Ubuntu.t
b/scripts/t/Dpkg_BuildFlags_Ubuntu.t
index 193e49269..2f8827f80 100644
--- a/scripts/t/Dpkg_BuildFlags_Ubuntu.t
+++ b/scripts/t/Dpkg_BuildFlags_Ubuntu.t
@@ -16,7 +16,7 @@
use strict;
use warnings;
-use Test::More tests => 18;
+use Test::More tests => 21;
BEGIN {
use_ok('Dpkg::BuildFlags');
@@ -42,6 +42,15 @@ sub test_ltoflag
"LDFLAGS contains LTO flags on $ENV{DEB_HOST_ARCH}");
}
+sub test_no_ltoflag
+{
+my $bf = shift;
+
+# Test the LTO flags not enabled.
+ok($bf->get('LDFLAGS') !~ m/-flto=auto -ffat-lto-objects/,
+"LDFLAGS doesn't contains LTO flags on $ENV{DEB_HOST_ARCH}");
+}
+
my $bf;
# Force loading the Dpkg::Vendor::Ubuntu module.
@@ -65,4 +74,21 @@ $bf = Dpkg::BuildFlags->new();
test_optflag($bf, '-O3');
test_ltoflag($bf);
+# Test the optimization flag not enabled for riscv64.
+$ENV{DEB_HOST_ARCH} = 'riscv64';
+$bf = Dpkg::BuildFlags->new();
+
+test_no_ltoflag($bf);
+
+# Test the optimization flag overrided by DEB_BUILD_MAINT_OPTIONS.
+$ENV{DEB_BUILD_MAINT_OPTIONS} = 'optimize=+lto';
+$bf = Dpkg::BuildFlags->new();
+
+test_ltoflag($bf);
+
+$ENV{DEB_HOST_ARCH} = 'amd64';
+$ENV{DEB_BUILD_MAINT_OPTIONS} = 'optimize=-lto';
+$bf = Dpkg::BuildFlags->new();
+test_no_ltoflag($bf);
+
1;
--
2.39.0
Bug#1028452: unblock: golang-1.19/1.19.5-1
On Thu, Jan 12, 2023 at 11:28 PM Paul Gevers wrote: > > Hi Shengjing, > > On 11-01-2023 09:32, Shengjing Zhu wrote: > > Please unblock package golang-1.19 > > But golang-1.19 is in sync between unstable and testing. > Because I haven't uploaded. This unblock request is for 1.19.5-1, while unstable has 1.19.4-1. > > This is a point release for golang 1.19 which happens today. > > I suspect you're asking for an exception as golang is on our toolchain > list [0]? In *my* interpretation of the freeze date, you have until > today to upload. (Yes, I know others in the team have argued differently > on irc, we'll need to clarify that better next round). So, if you're > quick you didn't even *need* to ask for an exception if you otherwise > meet the criteria [1]. Please check and if you meet them, go ahead if > you upload happens within 2 days. > Yes, for toolchain freeze. golang-1.19 doesn't have autopkgtest for itself. So it will take 5 days to migrate. So it's already late for me to upload. As I read the backlog on irc, when someone asks for rust update, they are told the package should be in testing when the freeze starts. > > + Many Go packages still record Built-Using field, so this upload will > > block >Go packages from migration. Release team need to rebuild outdated > Built-Using. > > I don't think it blocks migration (but maybe I'm misunderstanding what > you mean). But why hasn't this been fixed by now? Do you know if bugs > have been filed? > I mean if I upload golang-1.19 to unstable, and if it's unapproved to migrate to testing, then any Go packages built with golang-1.19/unstable will be blocked on migration. Since they have Built-Using of golang-1.19/unstable, and must be migrated after golang-1.19. And for abuse of Built-Using field, dpkg has added a new field, which is called Static-Built-Using. Anthony Fok has implemented it in dh-golang, and has migrated some packages to use that new field. But this is not something that can be automated. So all Go packages need manual update. There's no call for doing this inside the team yet. That's slow in progress. > >The Go point release or security release may happen several times during > > freeze. > >What kind of release can be expected to be unblocked during freeze? > > Again, it's written in [1]. Please let me know if there's something unclear. > > But this bug report triggered me: did the golang security situation > already improved during this release cycle. I may be misremembering, but > I recall the problems on the security archive side haven't been fixed, > have they? > For some reference, I did several security updates for golang-1.15 for bullseye, but we didn't rebuild other packages. These security updates are not urgent enough anyway. And others also update some Go packages for bullseye. In general, we just do the usual update for stable release. As for the security archive, IIRC, for bullseye, the security team did need to ask ftp-master to copy some individual packages manually. I'm not sure how it is going now. But given the low update frequency I overseved for bullseye, probably that works. -- Shengjing Zhu
Bug#1028452: unblock: golang-1.19/1.19.5-1
On Thu, Jan 12, 2023 at 11:28 PM Paul Gevers wrote: > > Hi Shengjing, > > On 11-01-2023 09:32, Shengjing Zhu wrote: > > Please unblock package golang-1.19 > > But golang-1.19 is in sync between unstable and testing. > Because I haven't uploaded. This unblock request is for 1.19.5-1, while unstable has 1.19.4-1. > > This is a point release for golang 1.19 which happens today. > > I suspect you're asking for an exception as golang is on our toolchain > list [0]? In *my* interpretation of the freeze date, you have until > today to upload. (Yes, I know others in the team have argued differently > on irc, we'll need to clarify that better next round). So, if you're > quick you didn't even *need* to ask for an exception if you otherwise > meet the criteria [1]. Please check and if you meet them, go ahead if > you upload happens within 2 days. > Yes, for toolchain freeze. golang-1.19 doesn't have autopkgtest for itself. So it will take 5 days to migrate. So it's already late for me to upload. As I read the backlog on irc, when someone asks for rust update, they are told the package should be in testing when the freeze starts. > > + Many Go packages still record Built-Using field, so this upload will > > block >Go packages from migration. Release team need to rebuild outdated > Built-Using. > > I don't think it blocks migration (but maybe I'm misunderstanding what > you mean). But why hasn't this been fixed by now? Do you know if bugs > have been filed? > I mean if I upload golang-1.19 to unstable, and if it's unapproved to migrate to testing, then any Go packages built with golang-1.19/unstable will be blocked on migration. Since they have Built-Using of golang-1.19/unstable, and must be migrated after golang-1.19. And for abuse of Built-Using field, dpkg has added a new field, which is called Static-Built-Using. Anthony Fok has implemented it in dh-golang, and has migrated some packages to use that new field. But this is not something that can be automated. So all Go packages need manual update. There's no call for doing this inside the team yet. That's slow in progress. > >The Go point release or security release may happen several times during > > freeze. > >What kind of release can be expected to be unblocked during freeze? > > Again, it's written in [1]. Please let me know if there's something unclear. > > But this bug report triggered me: did the golang security situation > already improved during this release cycle. I may be misremembering, but > I recall the problems on the security archive side haven't been fixed, > have they? > For some reference, I did several security updates for golang-1.15 for bullseye, but we didn't rebuild other packages. These security updates are not urgent enough anyway. And others also update some Go packages for bullseye. In general, we just do the usual update for stable release. As for the security archive, IIRC, for bullseye, the security team did need to ask ftp-master to copy some individual packages manually. I'm not sure how it is going now. But given the low update frequency I overseved for bullseye, probably that works. -- Shengjing Zhu
Bug#1027912: marked as pending in golang-go.uber-atomic
Control: tag -1 pending Hello, Bug #1027912 in golang-go.uber-atomic reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/go-team/packages/golang-go.uber-atomic/-/commit/f995364b842cdb125d5f02aeb45b8f04a4887faa Add tzdata to Build-Depends (Closes: #1027912) (this message was generated automatically) -- Greetings https://bugs.debian.org/1027912
Bug#1028525: RM: golang-github-marten-seemann-qtls -- RoQA; obsoleted library for golang < 1.15
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: golang-github-marten-seemann-q...@packages.debian.org, z...@debian.org Control: affects -1 + src:golang-github-marten-seemann-qtls This is library is for golang < 1.15, which is no longer available for a long time. And the upstream repo is also archived.
Bug#1028524: RM: golang-github-marten-seemann-qtls-go1-18 -- RoQA; obsoleted library for golang-1.18
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-18 This is only used when building with golang-1.18. The default golang has been bumped to 1.19 for a long time. And there's no reverse dependency for it now.
Re: golang-golang-x-oauth2 ready for upload
On Thu, Jan 12, 2023 at 4:18 PM M Hickford wrote: > > Hi. Could anyone here help upload > https://salsa.debian.org/go-team/packages/golang-golang-x-oauth2 ? > > https://tracker.debian.org/pkg/golang-golang-x-oauth2 "vcswatch > reports that this package seems to have a new changelog entry (version > 0.4.0-1, distribution unstable) and new commits in its VCS. You should > consider whether it's time to make an upload." > Any reason why you want to update to 0.4.0? There is no code change in 0.3.0 and 0.4.0. I prefer to save some build time currently. -- Shengjing Zhu
Bug#1028452: unblock: golang-1.19/1.19.5-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: golang-1...@packages.debian.org, z...@debian.org
Control: affects -1 + src:golang-1.19
Please unblock package golang-1.19
This is a point release for golang 1.19 which happens today.
[ Reason ]
Update the latest release.
[ Impact ]
If we can be closer to upstream latest release, it will be easier to backport
security patch for bookworm.
[ Tests ]
Upstream does well tests. And I have tried to use the new version to compile
some programs.
[ Risks ]
The history record for golang point release doesn't show regressions.
[ 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 ]
+ This package doesn't have autopkgtest.
+ Many Go packages still record Built-Using field, so this upload will block
Go packages from migration. Release team need to rebuild outdated Built-Using.
The Go point release or security release may happen several times during
freeze.
What kind of release can be expected to be unblocked during freeze?
unblock golang-1.19/1.19.5-1
diff -Nru golang-1.19-1.19.4/debian/changelog
golang-1.19-1.19.5/debian/changelog
--- golang-1.19-1.19.4/debian/changelog 2022-12-07 06:10:54.0 +0800
+++ golang-1.19-1.19.5/debian/changelog 2023-01-11 15:35:00.0 +0800
@@ -1,3 +1,13 @@
+golang-1.19 (1.19.5-1) unstable; urgency=medium
+
+ * Team upload
+ * Add NO_PNG_PKG_MANGLE to prevent mangling testdata.
+This is Ubuntu specific behaviour so they can sync the package without
+vendor patch.
+ * New upstream version 1.19.5
+
+ -- Shengjing Zhu Wed, 11 Jan 2023 15:35:00 +0800
+
golang-1.19 (1.19.4-1) unstable; urgency=medium
* New upstream version 1.19.4
diff -Nru golang-1.19-1.19.4/debian/rules golang-1.19-1.19.5/debian/rules
--- golang-1.19-1.19.4/debian/rules 2022-12-07 06:10:54.0 +0800
+++ golang-1.19-1.19.5/debian/rules 2023-01-11 15:35:00.0 +0800
@@ -7,6 +7,9 @@
# for DEB_VERSION_UPSTREAM
include /usr/share/dpkg/pkg-info.mk
+# Ubuntu mangles png files by default, which can break the testdata.
+export NO_PNG_PKG_MANGLE := 1
+
export GOVER := $(shell echo $(DEB_VERSION_UPSTREAM) | grep -oP
'^([0-9]+\.[0-9]+)')
export GOROOT := $(CURDIR)
diff -Nru golang-1.19-1.19.4/misc/cgo/testcshared/cshared_test.go
golang-1.19-1.19.5/misc/cgo/testcshared/cshared_test.go
--- golang-1.19-1.19.4/misc/cgo/testcshared/cshared_test.go 2022-12-02
02:12:53.0 +0800
+++ golang-1.19-1.19.5/misc/cgo/testcshared/cshared_test.go 2023-01-10
06:38:01.0 +0800
@@ -329,30 +329,46 @@
if err != nil {
return fmt.Errorf("unable to find dlltool path:
%v\n%s\n", err, out)
}
- args := []string{strings.TrimSpace(string(out)), "-D", args[6],
"-l", libgoname, "-d", "libgo.def"}
-
- // This is an unfortunate workaround for
https://github.com/mstorsjo/llvm-mingw/issues/205 in which
- // we basically reimplement the contents of the dlltool.sh
wrapper: https://git.io/JZFlU
- dlltoolContents, err := os.ReadFile(args[0])
- if err != nil {
- return fmt.Errorf("unable to read dlltool: %v\n", err)
+ dlltoolpath := strings.TrimSpace(string(out))
+ if filepath.Ext(dlltoolpath) == "" {
+ // Some compilers report slash-separated paths without
extensions
+ // instead of ordinary Windows paths.
+ // Try to find the canonical name for the path.
+ if lp, err := exec.LookPath(dlltoolpath); err == nil {
+ dlltoolpath = lp
+ }
}
- if bytes.HasPrefix(dlltoolContents, []byte("#!/bin/sh")) &&
bytes.Contains(dlltoolContents, []byte("llvm-dlltool")) {
- base, name := filepath.Split(args[0])
- args[0] = filepath.Join(base, "llvm-dlltool")
- var machine string
- switch prefix, _, _ := strings.Cut(name, "-"); prefix {
- case "i686":
- machine = "i386"
- case "x86_64":
- machine = "i386:x86-64"
- case "armv7":
- machine = "arm"
- case "aarch64":
- machine = "arm64"
+
+ args := []string{dlltoolpath, "-D", args[6], "-l", libgoname,
"-d", "libgo.def"
Bug#1028452: unblock: golang-1.19/1.19.5-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: golang-1...@packages.debian.org, z...@debian.org
Control: affects -1 + src:golang-1.19
Please unblock package golang-1.19
This is a point release for golang 1.19 which happens today.
[ Reason ]
Update the latest release.
[ Impact ]
If we can be closer to upstream latest release, it will be easier to backport
security patch for bookworm.
[ Tests ]
Upstream does well tests. And I have tried to use the new version to compile
some programs.
[ Risks ]
The history record for golang point release doesn't show regressions.
[ 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 ]
+ This package doesn't have autopkgtest.
+ Many Go packages still record Built-Using field, so this upload will block
Go packages from migration. Release team need to rebuild outdated Built-Using.
The Go point release or security release may happen several times during
freeze.
What kind of release can be expected to be unblocked during freeze?
unblock golang-1.19/1.19.5-1
diff -Nru golang-1.19-1.19.4/debian/changelog
golang-1.19-1.19.5/debian/changelog
--- golang-1.19-1.19.4/debian/changelog 2022-12-07 06:10:54.0 +0800
+++ golang-1.19-1.19.5/debian/changelog 2023-01-11 15:35:00.0 +0800
@@ -1,3 +1,13 @@
+golang-1.19 (1.19.5-1) unstable; urgency=medium
+
+ * Team upload
+ * Add NO_PNG_PKG_MANGLE to prevent mangling testdata.
+This is Ubuntu specific behaviour so they can sync the package without
+vendor patch.
+ * New upstream version 1.19.5
+
+ -- Shengjing Zhu Wed, 11 Jan 2023 15:35:00 +0800
+
golang-1.19 (1.19.4-1) unstable; urgency=medium
* New upstream version 1.19.4
diff -Nru golang-1.19-1.19.4/debian/rules golang-1.19-1.19.5/debian/rules
--- golang-1.19-1.19.4/debian/rules 2022-12-07 06:10:54.0 +0800
+++ golang-1.19-1.19.5/debian/rules 2023-01-11 15:35:00.0 +0800
@@ -7,6 +7,9 @@
# for DEB_VERSION_UPSTREAM
include /usr/share/dpkg/pkg-info.mk
+# Ubuntu mangles png files by default, which can break the testdata.
+export NO_PNG_PKG_MANGLE := 1
+
export GOVER := $(shell echo $(DEB_VERSION_UPSTREAM) | grep -oP
'^([0-9]+\.[0-9]+)')
export GOROOT := $(CURDIR)
diff -Nru golang-1.19-1.19.4/misc/cgo/testcshared/cshared_test.go
golang-1.19-1.19.5/misc/cgo/testcshared/cshared_test.go
--- golang-1.19-1.19.4/misc/cgo/testcshared/cshared_test.go 2022-12-02
02:12:53.0 +0800
+++ golang-1.19-1.19.5/misc/cgo/testcshared/cshared_test.go 2023-01-10
06:38:01.0 +0800
@@ -329,30 +329,46 @@
if err != nil {
return fmt.Errorf("unable to find dlltool path:
%v\n%s\n", err, out)
}
- args := []string{strings.TrimSpace(string(out)), "-D", args[6],
"-l", libgoname, "-d", "libgo.def"}
-
- // This is an unfortunate workaround for
https://github.com/mstorsjo/llvm-mingw/issues/205 in which
- // we basically reimplement the contents of the dlltool.sh
wrapper: https://git.io/JZFlU
- dlltoolContents, err := os.ReadFile(args[0])
- if err != nil {
- return fmt.Errorf("unable to read dlltool: %v\n", err)
+ dlltoolpath := strings.TrimSpace(string(out))
+ if filepath.Ext(dlltoolpath) == "" {
+ // Some compilers report slash-separated paths without
extensions
+ // instead of ordinary Windows paths.
+ // Try to find the canonical name for the path.
+ if lp, err := exec.LookPath(dlltoolpath); err == nil {
+ dlltoolpath = lp
+ }
}
- if bytes.HasPrefix(dlltoolContents, []byte("#!/bin/sh")) &&
bytes.Contains(dlltoolContents, []byte("llvm-dlltool")) {
- base, name := filepath.Split(args[0])
- args[0] = filepath.Join(base, "llvm-dlltool")
- var machine string
- switch prefix, _, _ := strings.Cut(name, "-"); prefix {
- case "i686":
- machine = "i386"
- case "x86_64":
- machine = "i386:x86-64"
- case "armv7":
- machine = "arm"
- case "aarch64":
- machine = "arm64"
+
+ args := []string{dlltoolpath, "-D", args[6], "-l", libgoname,
"-d", "libgo.def"
[pkg-go] Bug#1028448: RM: golang-gopkg-olivere-elastic.v3 -- RoQA; reduce version of golang-gopkg-olivere-elastic
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: golang-gopkg-olivere-elastic...@packages.debian.org, z...@debian.org Control: affects -1 + src:golang-gopkg-olivere-elastic.v3 We have 3 golang-gopkg-olivere-elastic.vN packages. + golang-gopkg-olivere-elastic.v2-dev + golang-gopkg-olivere-elastic.v3-dev + golang-gopkg-olivere-elastic.v5-dev v2 still has reverse dependency. v5 is the latest. So v3 can be removed. ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
Bug#1028448: RM: golang-gopkg-olivere-elastic.v3 -- RoQA; reduce version of golang-gopkg-olivere-elastic
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: golang-gopkg-olivere-elastic...@packages.debian.org, z...@debian.org Control: affects -1 + src:golang-gopkg-olivere-elastic.v3 We have 3 golang-gopkg-olivere-elastic.vN packages. + golang-gopkg-olivere-elastic.v2-dev + golang-gopkg-olivere-elastic.v3-dev + golang-gopkg-olivere-elastic.v5-dev v2 still has reverse dependency. v5 is the latest. So v3 can be removed.
Bug#1028446: RM: golang-gopkg-ldap.v3 -- RoQA; duplicated with golang-github-go-ldap-ldap
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: golang-gopkg-ldap...@packages.debian.org, deb...@alteholz.de, z...@debian.org Control: affects -1 + src:golang-gopkg-ldap.v3 These two packages are same upstream, same major version. There's no reverse dependency for golang-gopkg-ldap.v3.
Bug#1028445: RM: golang-gopkg-go-playground-assert.v1 -- ROM; superseded by golang-github-go-playground-assert-v2
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: golang-gopkg-go-playground-assert...@packages.debian.org, z...@debian.org Control: affects -1 + src:golang-gopkg-go-playground-assert.v1 The new version is packaged in new source golang-github-go-playground-assert-v2. Please remove golang-gopkg-go-playground-validator.v8 first (#1028444), then it has no dependency issue.
Bug#1028444: RM: golang-gopkg-go-playground-validator.v8 -- ROM; superseded by golang-github-go-playground-validator-v10
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: golang-gopkg-go-playground-validator...@packages.debian.org, z...@debian.org Control: affects -1 + src:golang-gopkg-go-playground-validator.v8 The new version of go-playground-validator is packaged in new source. There's no reverse dependency for golang-gopkg-go-playground-validator.v8
Bug#1028384: RM: golang-github-wellington-go-libsass -- RoQA; Old sass library for hugo which now uses golang-github-bep-golibsass
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: golang-github-wellington-go-libs...@packages.debian.org, f...@debian.org, z...@debian.org Control: affects -1 + src:golang-github-wellington-go-libsass This package along with golang-github-bep-go-tocss are packaged for hugo, but hugo now uses golang-github-bep-golibsass. P.S. need to remove golang-github-bep-go-tocss (#1028382) first for dependency issue.
Bug#1028382: RM: golang-github-bep-go-tocss -- RoQA; superseded by golang-github-bep-golibsass; upstream repo archived
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: golang-github-bep-go-to...@packages.debian.org, z...@debian.org, f...@debian.org Control: affects -1 + src:golang-github-bep-go-tocss golang-github-bep-go-tocss is packaged for hugo, but hugo now uses golang-github-bep-golibsass. Besides go-tocss upstream has discontinued. See https://github.com/bep/go-tocss
Re: Dropping /usr/share/zoneinfo/posix and /usr/share/zoneinfo/right from tzdata
Hi, On Tue, Jan 10, 2023 at 2:01 AM Benjamin Drung wrote: > > Hi everyone, > > The tzdata package ships /usr/share/zoneinfo/posix/ (for Coordinated > Universal Time) and /usr/share/zoneinfo/right/ (for International Atomic > Time). The files in /usr/share/zoneinfo/posix/ are identical to their > counterpart in /usr/share/zoneinfo/. The tzdata package converts the > configured posix/* and right/* timezones to their unprefixed variant on > every package upgrade (e.g. it changes "posix/Europe/Berlin" to > "Europe/Berlin"). > > Is there anybody actually using /usr/share/zoneinfo/posix or > /usr/share/zoneinfo/right? > After a quick search[1][2] I find, + moment-timezone.js + rdate + https://github.com/facebook/time/blob/main/leapsectz/leapsectz.go [1] https://codesearch.debian.net/search?q=%2Fusr%2Fshare%2Fzoneinfo%2F%28posix%7Cright%29=0 [2] https://grep.app/search?q=/usr/share/zoneinfo/%28posix%7Cright%29=true -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Should singularity-container make it to next release?
Hi Nilesh, On Mon, Jan 9, 2023 at 6:21 PM Nilesh Patra wrote: > I started this thread a while back, and decided to simply ask upstream about > what their > opinion is[9] > It looks like the situation still not fully certain on whether to let > singularity make it to stable > or not. > > I'd appreciate if someone on the list could chime in and give an opinion on > if they > consider it do-able or not for upcoming bookworm release. > Could you list the concerns that you have? + Security support? I see upstream comments that they will disclose the relevant fix/commit for CVE, then it should be enough. I think most packages in Debian rely on the Debian maintainer to backport the fix. + Lacking tests? (as per upstream concerns in the Github issue) Do you plan to enable all the tests? I see you have disabled many tests[1] Or even better, could you run the integration/e2e tests with autopkgtest? For example, you can take a look at the containerd package that I've maintained[2]. [1] https://salsa.debian.org/hpc-team/singularity-container/-/blob/debian/3.10.3+ds1-1/debian/rules#L68 [2] https://salsa.debian.org/go-team/packages/containerd/-/blob/debian/sid/debian/tests/cri-integration https://salsa.debian.org/go-team/packages/containerd/-/blob/debian/sid/debian/tests/integration -- Shengjing Zhu
Bug#1028222: Don't release for bookworm
Source: golang-1.20 Version: 1.20~rc2-1 Severity: serious X-Debbugs-Cc: z...@debian.org Control: clone -1 -2 Control: reassign -2 src:golang-1.18 1.18.9-1 Usually we only keep one go compiler in stable. For bookworm it should be golang-1.19.
Bug#1028222: Don't release for bookworm
Source: golang-1.20 Version: 1.20~rc2-1 Severity: serious X-Debbugs-Cc: z...@debian.org Control: clone -1 -2 Control: reassign -2 src:golang-1.18 1.18.9-1 Usually we only keep one go compiler in stable. For bookworm it should be golang-1.19.
Bug#1028100: Anbox's README.Debian points to a defunct website for downloading images
Control: tags -1 wontfix upstream On Sat, Jan 7, 2023 at 5:12 AM Alain Knaff wrote: > > Package: anbox > Version: 0.0~git20210106-1 > > Hi, > > In order to use the anbox android emulator, you first need to download > an android image, and put it into /var/lib/anbox/android.img. > > /usr/share/doc/anbox/README.Debian gives a source URL for these images: > https://build.anbox.io/android-images > but unfortunately the site seems to be defunct. Name is still defined, > but connection attempts time out. > > Please update with an URL that is still valid today > Unfortunately, there's nothing we can do in Debian. The server is provided by upstream, and they only have this address. It's just that the anbox project is abandoned by upstream. -- Shengjing Zhu
Bug#1027707: patroni: autopkgtest fails with etcd 3.4 (v2 not enabled by default)
Hi, On Mon, Jan 2, 2023 at 6:35 PM Shengjing Zhu wrote: > > Source: patroni > Version: 2.1.5-1 > Severity: serious > > Hi, > > I've uploaded etcd 3.4 to unstable. Your package's autopkgtest fails. > I believe it's because etcd 3.4 doesn't enable v2 API by default. > Please adjust your autopkgtest with ETCD_ENABLE_V2=true env, or --enable-v2 > option. I noticed you uploaded 2.1.6 which has --enable-v2. But the autopkgtest failure still exists. I tried to reproduce it locally with the 2.1.6 version. First I run autopkgtest with the schroot backend, and I can't reproduce the error. The I tried the lxd backend. Now I indeed found the error. # autopkgtest -B -s --test-name=acceptance-etcd-basic patroni_2.1.6-1.dsc -- lxd autopkgtest/debian/unstable/amd64 root@autopkgtest-lxd-jzdcwl:/tmp/autopkgtest.VeGcZ8/build.2LX/src# cat features/output/etcd.log 2023-01-07 14:04:06.932041 W | pkg/flags: unrecognized environment variable ETCD_UNSUPPORTED_ARCH= [WARNING] Deprecated '--logger=capnslog' flag is set; use '--logger=zap' flag instead 2023-01-07 14:04:06.932117 I | etcdmain: etcd Version: 3.4.23 2023-01-07 14:04:06.932125 I | etcdmain: Git SHA: Not provided (use ./build instead of go build) 2023-01-07 14:04:06.932132 I | etcdmain: Go Version: go1.19.4 2023-01-07 14:04:06.932139 I | etcdmain: Go OS/Arch: linux/amd64 2023-01-07 14:04:06.932146 I | etcdmain: setting maximum number of CPUs to 4, total number of available CPUs is 4 [WARNING] Deprecated '--logger=capnslog' flag is set; use '--logger=zap' flag instead 2023-01-07 14:04:06.932839 C | etcdmain: listen tcp 127.0.0.1:2380: bind: address already in use root@autopkgtest-lxd-jzdcwl:/tmp/autopkgtest.VeGcZ8/build.2LX/src# systemctl status etcd ● etcd.service - etcd - highly-available key value store Loaded: loaded (/lib/systemd/system/etcd.service; enabled; preset: enabled) Drop-In: /run/systemd/system/service.d └─zzz-lxc-service.conf Active: active (running) since Sat 2023-01-07 14:03:46 UTC; 44s ago Docs: https://etcd.io/docs man:etcd Main PID: 1677 (etcd) Tasks: 10 (limit: 9324) Memory: 31.1M CPU: 568ms CGroup: /system.slice/etcd.service └─1677 /usr/bin/etcd There is an etcd instance running. So you test can't start a new one. I'm not sure why etcd 3.4 behaviors differently with 3.3. But it doesn't seem wrong for etcd. So could you mask or kill etcd instances before running tests? I can run the test successfully with following command: autopkgtest --setup-commands="systemctl mask etcd" -U -B -s --test-name=acceptance-etcd-basic patroni_2.1.6-1.dsc -- lxd autopkgtest/debian/unstable/amd64 -- Shengjing Zhu
Bug#1027707: patroni: autopkgtest fails with etcd 3.4 (v2 not enabled by default)
Hi, On Mon, Jan 2, 2023 at 6:35 PM Shengjing Zhu wrote: > > Source: patroni > Version: 2.1.5-1 > Severity: serious > > Hi, > > I've uploaded etcd 3.4 to unstable. Your package's autopkgtest fails. > I believe it's because etcd 3.4 doesn't enable v2 API by default. > Please adjust your autopkgtest with ETCD_ENABLE_V2=true env, or --enable-v2 > option. I noticed you uploaded 2.1.6 which has --enable-v2. But the autopkgtest failure still exists. I tried to reproduce it locally with the 2.1.6 version. First I run autopkgtest with the schroot backend, and I can't reproduce the error. The I tried the lxd backend. Now I indeed found the error. # autopkgtest -B -s --test-name=acceptance-etcd-basic patroni_2.1.6-1.dsc -- lxd autopkgtest/debian/unstable/amd64 root@autopkgtest-lxd-jzdcwl:/tmp/autopkgtest.VeGcZ8/build.2LX/src# cat features/output/etcd.log 2023-01-07 14:04:06.932041 W | pkg/flags: unrecognized environment variable ETCD_UNSUPPORTED_ARCH= [WARNING] Deprecated '--logger=capnslog' flag is set; use '--logger=zap' flag instead 2023-01-07 14:04:06.932117 I | etcdmain: etcd Version: 3.4.23 2023-01-07 14:04:06.932125 I | etcdmain: Git SHA: Not provided (use ./build instead of go build) 2023-01-07 14:04:06.932132 I | etcdmain: Go Version: go1.19.4 2023-01-07 14:04:06.932139 I | etcdmain: Go OS/Arch: linux/amd64 2023-01-07 14:04:06.932146 I | etcdmain: setting maximum number of CPUs to 4, total number of available CPUs is 4 [WARNING] Deprecated '--logger=capnslog' flag is set; use '--logger=zap' flag instead 2023-01-07 14:04:06.932839 C | etcdmain: listen tcp 127.0.0.1:2380: bind: address already in use root@autopkgtest-lxd-jzdcwl:/tmp/autopkgtest.VeGcZ8/build.2LX/src# systemctl status etcd ● etcd.service - etcd - highly-available key value store Loaded: loaded (/lib/systemd/system/etcd.service; enabled; preset: enabled) Drop-In: /run/systemd/system/service.d └─zzz-lxc-service.conf Active: active (running) since Sat 2023-01-07 14:03:46 UTC; 44s ago Docs: https://etcd.io/docs man:etcd Main PID: 1677 (etcd) Tasks: 10 (limit: 9324) Memory: 31.1M CPU: 568ms CGroup: /system.slice/etcd.service └─1677 /usr/bin/etcd There is an etcd instance running. So you test can't start a new one. I'm not sure why etcd 3.4 behaviors differently with 3.3. But it doesn't seem wrong for etcd. So could you mask or kill etcd instances before running tests? I can run the test successfully with following command: autopkgtest --setup-commands="systemctl mask etcd" -U -B -s --test-name=acceptance-etcd-basic patroni_2.1.6-1.dsc -- lxd autopkgtest/debian/unstable/amd64 -- Shengjing Zhu
Bug#1027369: marked as pending in golang-github-mohae-deepcopy
Control: tag -1 pending Hello, Bug #1027369 in golang-github-mohae-deepcopy reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/go-team/packages/golang-github-mohae-deepcopy/-/commit/c9bcf3e13e79fa51c6c4eef1837b63e4030e6d81 Add tzdata to Build-Depends (Closes: #1027369) (this message was generated automatically) -- Greetings https://bugs.debian.org/1027369
Bug#1028065: RM: golang-go-dbus -- RoQA; ancient library; ftbfs for a long time; not in stable
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: golang-go-d...@packages.debian.org, z...@debian.org Control: affects -1 + src:golang-go-dbus This golang dbus library is not used anymore. Alternative is golang-dbus package which is well maintained.
Bug#1028064: RM: golang-github-marten-seemann-qtls-go1-17 -- RoQA; Old library for golang 1.17 which is removed
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-17 This library is for golang 1.17, which was removed on 2022-10-10.
Bug#1028044: $bf->strip can't strip duplicated flags
Package: libdpkg-perl Version: 1.21.13 Severity: normal X-Debbugs-Cc: z...@debian.org Given input `-flto=auto -flto=auto`, $bf->strip($flag, "-flto=auto") returns `-flto=auto`. However if given `-flto=auto -ffat-lto-objects -flto=auto`, it will return `-ffat-lto-objects`. (two -flto=auto are tripped) I read the code has `g` in regexp, so I think you want to strip duplicated flag. But the regexp pattern is bit buggy when two duplicated flags are together. Background: In dh-golang, I use $bf->strip to strip lto flags https://salsa.debian.org/go-team/packages/dh-golang/-/merge_requests/18 It works for a while in Debian. But I found Ubuntu still carries an LTO patch in the Go compiler. Then I wonder whether my dh-golang hack doesn't work for them. In Ubuntu, for unknown reason, their dpkg-buildflags gives a duplicated lto flags. `-flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects`. After $bf->strip($flag, "-ffat-lto-objects -flto=auto"), it becomes `-flto=auto`. Still one lto flag left...
Bug#1028044: $bf->strip can't strip duplicated flags
Package: libdpkg-perl Version: 1.21.13 Severity: normal X-Debbugs-Cc: z...@debian.org Given input `-flto=auto -flto=auto`, $bf->strip($flag, "-flto=auto") returns `-flto=auto`. However if given `-flto=auto -ffat-lto-objects -flto=auto`, it will return `-ffat-lto-objects`. (two -flto=auto are tripped) I read the code has `g` in regexp, so I think you want to strip duplicated flag. But the regexp pattern is bit buggy when two duplicated flags are together. Background: In dh-golang, I use $bf->strip to strip lto flags https://salsa.debian.org/go-team/packages/dh-golang/-/merge_requests/18 It works for a while in Debian. But I found Ubuntu still carries an LTO patch in the Go compiler. Then I wonder whether my dh-golang hack doesn't work for them. In Ubuntu, for unknown reason, their dpkg-buildflags gives a duplicated lto flags. `-flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects`. After $bf->strip($flag, "-ffat-lto-objects -flto=auto"), it becomes `-flto=auto`. Still one lto flag left...
Bug#1027994: cadvisor fails to gather process metrics on bullseye because of cgroup change
On Fri, Jan 6, 2023 at 2:00 AM Sukhbir Singh wrote: > a new release of the cadvisor package is warranted. > The current version in sid is broken for a long time. And it won't make it to bookworm. I no longer use cadvisor. So it really needs a new maintainer. -- Shengjing Zhu
Bug#1027994: cadvisor fails to gather process metrics on bullseye because of cgroup change
On Fri, Jan 6, 2023 at 2:00 AM Sukhbir Singh wrote: > a new release of the cadvisor package is warranted. > The current version in sid is broken for a long time. And it won't make it to bookworm. I no longer use cadvisor. So it really needs a new maintainer. -- Shengjing Zhu
Bug#1023284: libevent: FTBFS with glibc 2.36
On Fri, Nov 25, 2022 at 10:56:09AM -0500, Nicolas Mora wrote:
> Hello,
>
> Le 2022-11-17 à 04 h 15, Benjamin Drung a écrit :
> >
> > We did a library transition in Ubuntu to remove this symbol:
> > https://launchpad.net/bugs/1990941
> > Attached the patch we applied.
> >
> Thanks, I've made a new package based on your patch lately,
> libevent_2.1.12-stable-7 is in NEW for now [1]. Waiting for FTP masters to
> review the new package so the transition can start.
>
Probably late for this. But this really isn't right for a library transition.
I've read the discussion on launchpad. The orig patch to keep ABI has problem
for mixing arc4random functions from the vendored sources and glibc.
But as I read the code, the arc4random_addrandom shouldn't be called. So glibc
doesn't provide such.
(Why you want to add entropy yourself?)
Looking at other implementation that still has arc4random_addrandom, for example
https://docs.oracle.com/cd/E88353_01/html/E37843/arc4random-addrandom-3c.html
It's just empty function, provided for compatibility.
So Just make evutil_secure_rng_add_bytes noop with glibc's implemtation of
arc4random. Please see following patch.
diff --git a/evutil_rand.c b/evutil_rand.c
index 8e9afda..15deab3 100644
--- a/evutil_rand.c
+++ b/evutil_rand.c
@@ -190,14 +190,14 @@ evutil_secure_rng_get_bytes(void *buf, size_t n)
ev_arc4random_buf(buf, n);
}
-#if !defined(EVENT__HAVE_ARC4RANDOM) ||
defined(EVENT__HAVE_ARC4RANDOM_ADDRANDOM)
void
evutil_secure_rng_add_bytes(const char *buf, size_t n)
{
+#if defined(EVENT__HAVE_ARC4RANDOM_ADDRANDOM)
arc4random_addrandom((unsigned char*)buf,
n>(size_t)INT_MAX ? INT_MAX : (int)n);
-}
#endif
+}
void
evutil_free_secure_rng_globals_(void)
diff --git a/include/event2/util.h b/include/event2/util.h
index 02aa7ba..aa7177d 100644
--- a/include/event2/util.h
+++ b/include/event2/util.h
@@ -862,7 +862,6 @@ int evutil_secure_rng_init(void);
EVENT2_EXPORT_SYMBOL
int evutil_secure_rng_set_urandom_device_file(char *fname);
-#if !defined(EVENT__HAVE_ARC4RANDOM) ||
defined(EVENT__HAVE_ARC4RANDOM_ADDRANDOM)
/** Seed the random number generator with extra random bytes.
You should almost never need to call this function; it should be
@@ -879,7 +878,6 @@ int evutil_secure_rng_set_urandom_device_file(char *fname);
*/
EVENT2_EXPORT_SYMBOL
void evutil_secure_rng_add_bytes(const char *dat, size_t datlen);
-#endif
#ifdef __cplusplus
}
Bug#1023284: libevent: FTBFS with glibc 2.36
On Fri, Nov 25, 2022 at 10:56:09AM -0500, Nicolas Mora wrote:
> Hello,
>
> Le 2022-11-17 à 04 h 15, Benjamin Drung a écrit :
> >
> > We did a library transition in Ubuntu to remove this symbol:
> > https://launchpad.net/bugs/1990941
> > Attached the patch we applied.
> >
> Thanks, I've made a new package based on your patch lately,
> libevent_2.1.12-stable-7 is in NEW for now [1]. Waiting for FTP masters to
> review the new package so the transition can start.
>
Probably late for this. But this really isn't right for a library transition.
I've read the discussion on launchpad. The orig patch to keep ABI has problem
for mixing arc4random functions from the vendored sources and glibc.
But as I read the code, the arc4random_addrandom shouldn't be called. So glibc
doesn't provide such.
(Why you want to add entropy yourself?)
Looking at other implementation that still has arc4random_addrandom, for example
https://docs.oracle.com/cd/E88353_01/html/E37843/arc4random-addrandom-3c.html
It's just empty function, provided for compatibility.
So Just make evutil_secure_rng_add_bytes noop with glibc's implemtation of
arc4random. Please see following patch.
diff --git a/evutil_rand.c b/evutil_rand.c
index 8e9afda..15deab3 100644
--- a/evutil_rand.c
+++ b/evutil_rand.c
@@ -190,14 +190,14 @@ evutil_secure_rng_get_bytes(void *buf, size_t n)
ev_arc4random_buf(buf, n);
}
-#if !defined(EVENT__HAVE_ARC4RANDOM) ||
defined(EVENT__HAVE_ARC4RANDOM_ADDRANDOM)
void
evutil_secure_rng_add_bytes(const char *buf, size_t n)
{
+#if defined(EVENT__HAVE_ARC4RANDOM_ADDRANDOM)
arc4random_addrandom((unsigned char*)buf,
n>(size_t)INT_MAX ? INT_MAX : (int)n);
-}
#endif
+}
void
evutil_free_secure_rng_globals_(void)
diff --git a/include/event2/util.h b/include/event2/util.h
index 02aa7ba..aa7177d 100644
--- a/include/event2/util.h
+++ b/include/event2/util.h
@@ -862,7 +862,6 @@ int evutil_secure_rng_init(void);
EVENT2_EXPORT_SYMBOL
int evutil_secure_rng_set_urandom_device_file(char *fname);
-#if !defined(EVENT__HAVE_ARC4RANDOM) ||
defined(EVENT__HAVE_ARC4RANDOM_ADDRANDOM)
/** Seed the random number generator with extra random bytes.
You should almost never need to call this function; it should be
@@ -879,7 +878,6 @@ int evutil_secure_rng_set_urandom_device_file(char *fname);
*/
EVENT2_EXPORT_SYMBOL
void evutil_secure_rng_add_bytes(const char *dat, size_t datlen);
-#endif
#ifdef __cplusplus
}
[pkg-go] Bug#1027738: RM: golang-github-mvdan-xurls -- RoQA; superseded by golang-mvdan-xurls
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: golang-github-mvdan-xu...@packages.debian.org, z...@debian.org Control: affects -1 + src:golang-github-mvdan-xurls Hi, These two packages are same upstream. + golang-mvdan-xurls has newer version. + golang-github-mvdan-xurls has no reverse dependencies. ___ Pkg-go-maintainers mailing list Pkg-go-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers
Bug#1027738: RM: golang-github-mvdan-xurls -- RoQA; superseded by golang-mvdan-xurls
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: golang-github-mvdan-xu...@packages.debian.org, z...@debian.org Control: affects -1 + src:golang-github-mvdan-xurls Hi, These two packages are same upstream. + golang-mvdan-xurls has newer version. + golang-github-mvdan-xurls has no reverse dependencies.
Bug#1027707: patroni: autopkgtest fails with etcd 3.4 (v2 not enabled by default)
Source: patroni Version: 2.1.5-1 Severity: serious Hi, I've uploaded etcd 3.4 to unstable. Your package's autopkgtest fails. I believe it's because etcd 3.4 doesn't enable v2 API by default. Please adjust your autopkgtest with ETCD_ENABLE_V2=true env, or --enable-v2 option.
Bug#1027707: patroni: autopkgtest fails with etcd 3.4 (v2 not enabled by default)
Source: patroni Version: 2.1.5-1 Severity: serious Hi, I've uploaded etcd 3.4 to unstable. Your package's autopkgtest fails. I believe it's because etcd 3.4 doesn't enable v2 API by default. Please adjust your autopkgtest with ETCD_ENABLE_V2=true env, or --enable-v2 option.
Bug#1026793: docker.io: --memory-swap not enforced on systemd cgroup driver
Control: tag -1 unreproducible moreinfo On Mon, Jan 2, 2023 at 3:17 AM Shengjing Zhu wrote: > > Hi, > > On Wed, Dec 21, 2022 at 4:45 PM Saj Goonatilleke wrote: > > --- 8< --- > > # systemctl show docker-container-id.scope | awk -F = '$1 ~ /Memory.*Max/' > > MemoryMax=25165824 > > MemorySwapMax=infinity > > --- >8 --- > > > > From the cgroup: > > > > --- 8< --- > > # cat memory.swap.max > > max > > > > # cat memory.current memory.swap.current > > 22798336 > > 218423296 > > --- >8 --- > > > > I would expect memory.swap.max to read zero (swap - limit), > > and likewise for memory.swap.current. > > I can't reproduce it on unstable, with docker/20.10.21+dfsg1, > containerd/1.6.14~ds1, runc/1.1.4+ds1. > > $ docker run --rm --memory 1G --memory-swap 1G -it ubuntu:18.04 bash > root@65cc55e0f5f8:/# > > $ systemctl show > docker-65cc55e0f5f82c23bed45a8451c552650d7eebee182db991ecd855454fafaab7.scope > |grep MemorySwapMax= > MemorySwapMax=infinity > > $ cat > /sys/fs/cgroup/system.slice/docker-65cc55e0f5f82c23bed45a8451c552650d7eebee182db991ecd855454fafaab7.scope/memory.swap.max > 0 > > The systemd property seems wrong, but the cgroup value is right. So I > think it's not a big deal. > > I'll try to see if I can reproduce it on bullseye later. > Can't reproduce it on bullseye as well. debian@cloudimg:~$ sudo docker run --rm -itd --memory 1G --memory-swap 1G debian bash 5ccda9e406f85546afd5ccc61cf277cf0ed8f50ec80472d2641ae26d0c13d21e debian@cloudimg:~$ systemctl show docker-5ccda9e406f85546afd5ccc61cf277cf0ed8f50ec80472d2641ae26d0c13d21e.scope |grep MemorySw MemorySwapMax=infinity debian@cloudimg:~$ cat /sys/fs/cgroup/system.slice/docker-5ccda9e406f85546afd5ccc61cf277cf0ed8f50ec80472d2641ae26d0c13d21e.scope/memory.swap.max 0 debian@cloudimg:~$ cat /sys/fs/cgroup/system.slice/docker-5ccda9e406f85546afd5ccc61cf277cf0ed8f50ec80472d2641ae26d0c13d21e.scope/memory.max 1073741824 $ sudo docker version Client: Version: 20.10.5+dfsg1 API version: 1.41 Go version:go1.15.15 Git commit:55c4c88 Built: Mon May 30 18:34:49 2022 OS/Arch: linux/amd64 Context: default Experimental: true Server: Engine: Version: 20.10.5+dfsg1 API version: 1.41 (minimum version 1.12) Go version: go1.15.15 Git commit: 363e9a8 Built:Mon May 30 18:34:49 2022 OS/Arch: linux/amd64 Experimental: false containerd: Version: 1.4.13~ds1 GitCommit:1.4.13~ds1-1~deb11u3 runc: Version: 1.0.0~rc93+ds1 GitCommit:1.0.0~rc93+ds1-5+deb11u2 docker-init: Version: 0.19.0 GitCommit: debian@cloudimg:~$ uname -a Linux cloudimg 5.10.0-18-cloud-amd64 #1 SMP Debian 5.10.140-1 (2022-09-02) x86_64 GNU/Linux -- Shengjing Zhu
