Bug#1055059: nmu: runc_1.1.5+ds1-1+b4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: r...@packages.debian.org Control: affects -1 + src:runc nmu runc_1.1.5+ds1-1+b4 . ANY . unstable . -m "rebuild against golang-github-urfave-cli_1.22.14-1" please rebuild runc (again) to pickup dependency changes. I believe this rebuild to allow britney to detect the right combination of package version to allow runc to migrate. Thanks
Bug#1031097: bullseye-pu: package conmon/2.0.25+ds1-1.1
On 10/8/23 8:01 AM, Jonathan Wiltshire wrote: Hi, This request was approved but not uploaded in time for the previous point release (11.8). Should it be included in 11.9, or should this request be abandoned and closed? Apologies for dropping the ball here. I've just uploaded conmon 2.0.25+ds1-1.1 to bullseye. Looking forward to seeing it accepted for 11.9. -rt
Bug#1034493: bullseye-pu: package libpod/3.0.1+dfsg1-3+deb11u4
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: lib...@packages.debian.org Control: affects -1 + src:libpod [ Reason ] Podman relies on DBUS for correct functioning and reads the DBUS_SESSION_BUS_ADDRESS environent variables. As it turns out, some session managers use multiple values, separated by comma, to add additional information, such as a "guid". Unfortunately, an oversight in the parsing code in podman 3 fails to take multi-value items into account and leads to podman failing to connect to the session bus. This is a rebuild to pickup the changes approved via #1034198 [ Impact ] This is highly inconvenient to the users as they would have to either use a session manager that sets the DBUS_SESSION_BUS_ADDRESS without commas, or the user would have to sanitize the environment manually. Only very highly skilled users that happened to find https://github.com/containers/podman/issues/15546 or https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018816 would be able to figure this out. [ Tests ] This was manually tested. [ Risks ] the risk of regression is minimal, the patch was taken from upstream, and is included in later releases. [ 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 ] diff -Nru libpod-3.0.1+dfsg1/debian/changelog libpod-3.0.1+dfsg1/debian/changelog --- libpod-3.0.1+dfsg1/debian/changelog 2023-04-07 22:10:33.0 -0400 +++ libpod-3.0.1+dfsg1/debian/changelog 2023-04-16 18:16:11.0 -0400 @@ -1,3 +1,9 @@ +libpod (3.0.1+dfsg1-3+deb11u4) bullseye; urgency=medium + + * Recompile to fix parsing of DBUS_SESSION_BUS_ADDRESS (Closes: #1018816) + + -- Reinhard Tartler Sun, 16 Apr 2023 18:16:11 -0400 + libpod (3.0.1+dfsg1-3+deb11u3) bullseye; urgency=medium * Fix and tighten dependencies diff -Nru libpod-3.0.1+dfsg1/debian/control libpod-3.0.1+dfsg1/debian/control --- libpod-3.0.1+dfsg1/debian/control 2023-04-07 22:10:33.0 -0400 +++ libpod-3.0.1+dfsg1/debian/control 2023-04-16 18:16:11.0 -0400 @@ -18,7 +18,7 @@ ,golang-github-containerd-cgroups-dev ,golang-github-containernetworking-plugins-dev (>= 0.8.7) ,golang-github-containers-buildah-dev (>= 1.19.6) -,golang-github-containers-common-dev (>= 0.33.4+ds1-1+deb11u1) +,golang-github-containers-common-dev (>= 0.33.4+ds1-1+deb11u2) ,golang-github-containers-image-dev (>= 5.10.2) ,golang-github-containers-ocicrypt-dev ,golang-github-containers-psgo-dev (>= 1.5.2-1+deb11u1) @@ -137,7 +137,7 @@ ,golang-github-containerd-cgroups-dev ,golang-github-containernetworking-plugins-dev (>= 0.8.7) ,golang-github-containers-buildah-dev (>= 1.19) -,golang-github-containers-common-dev (>= 0.33.4+ds1-1+deb11u1) +,golang-github-containers-common-dev (>= 0.33.4+ds1-1+deb11u2) ,golang-github-containers-image-dev (>= 5.10) ,golang-github-containers-ocicrypt-dev ,golang-github-containers-psgo-dev (>= 1.5.2-1+deb11u1)
Bug#1034198: bullseye-pu: package golang-github-containers-common/0.33.4+ds1-1+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: golang-github-containers-com...@packages.debian.org,
siret...@tauware.de
Control: affects -1 + src:golang-github-containers-common
[ Reason ]
Podman relies on DBUS for correct functioning and reads the
DBUS_SESSION_BUS_ADDRESS environent variables. As it turns out, some session
managers use multiple values, separated by comma, to add additional
information, such as a "guid". Unfortunately, an oversight in the parsing code
in podman 3 fails to take multi-value items into account and leads to podman
failing to connect to the session bus.
[ Impact ]
This is highly inconvenient to the users as they would have to either use a
session manager that sets the DBUS_SESSION_BUS_ADDRESS without commas, or the
user would have to sanitize the environment manually. Only very highly skilled
users that happened to find https://github.com/containers/podman/issues/15546 or
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018816 would be able to
figure
this out.
[ Tests ]
This was manually tested.
[ Risks ]
the risk of regression is minimal, the patch was taken from upstream, and is
included
in later releases.
[ 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 ]
diff --git a/debian/changelog b/debian/changelog
index c23b4b9b..97d97794 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+golang-github-containers-common (0.33.4+ds1-1+deb11u2) bullseye; urgency=medium
+
+ * Fix parsing of DBUS_SESSION_BUS_ADDRESS, Closes: #1018816
+
+ -- Reinhard Tartler Mon, 10 Apr 2023 18:19:51 -0400
+
golang-github-containers-common (0.33.4+ds1-1+deb11u1) bullseye; urgency=medium
* Backport seccomp patches from upstream to allow execution of newer
diff --git a/debian/patches/DBUS_SESSION_BUS_ADDRESS_parsing.patch
b/debian/patches/DBUS_SESSION_BUS_ADDRESS_parsing.patch
new file mode 100644
index ..d1408a43
--- /dev/null
+++ b/debian/patches/DBUS_SESSION_BUS_ADDRESS_parsing.patch
@@ -0,0 +1,37 @@
+commit 47ea9a8cbcc35d1e758b01ae40f37fec8a2e310b
+Author: Giuseppe Scrivano
+Date: Mon Jul 26 15:00:25 2021 +0200
+
+config: split arguments in DBUS_SESSION_BUS_ADDRESS
+
+split the DBUS_SESSION_BUS_ADDRESS value so that something like:
+
+unix:path=/run/user/1000/bus,guid=817e9ffcfb383869ad17ea8360e7428a
+
+will ignore ",guid=817e9ffcfb383869ad17ea8360e7428a" when checking
+that the path exists.
+
+Closes: https://bugzilla.redhat.com/show_bug.cgi?id=1984531
+
+Signed-off-by: Giuseppe Scrivano
+
+--- a/pkg/config/config.go
b/pkg/config/config.go
+@@ -538,9 +538,14 @@
+
+ session := os.Getenv("DBUS_SESSION_BUS_ADDRESS")
+ hasSession := session != ""
+- if hasSession && strings.HasPrefix(session, "unix:path=") {
+- _, err := os.Stat(strings.TrimPrefix(session, "unix:path="))
+- hasSession = err == nil
++ if hasSession {
++ for _, part := range strings.Split(session, ",") {
++ if strings.HasPrefix(part, "unix:path=") {
++ _, err := os.Stat(strings.TrimPrefix(part,
"unix:path="))
++ hasSession = err == nil
++ break
++ }
++ }
+ }
+
+ if !hasSession {
diff --git a/debian/patches/series b/debian/patches/series
index c2a2b119..201ff0d9 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -6,3 +6,4 @@ seccomp-fixup.patch
08bbb0dfae71da36afd3be1ca104701e6cfa4406.patch
0f242ca74bd16175bc55013ed457c88137bec0cf.patch
689e5b074454da5228bb05604f89b7a876baa8fe.patch
+DBUS_SESSION_BUS_ADDRESS_parsing.patch
Bug#1034039: bullseye-pu: package libpod/3.0.1+dfsg1-3+deb11u1
Argh, my bad, I'll upload a new version later today Thanks for spotting -rt On April 7, 2023 4:41:41 AM EST, "Adam D. Barratt" wrote: >On Thu, 2023-04-06 at 19:46 -0400, Reinhard Tartler wrote: >> This code change picks up code changes in golang-github-containers- >> psgo >> and golang-github-containers-storage to fix CVE-2022-1227. This is >> reported >> as 1020907. This addresses a priviledge escalation issue when using >> 'podman top'. Upstream has more information in this issue in >> https://bugzilla.redhat.com/show_bug.cgi?id=2070368 >> > >I see this has already been uploaded; unfortunately: > >-,golang-github-containers-psgo-dev >-,golang-github-containers-storage-dev (>= 1.24.6) >+,golang-github-containers-psgo-dev (>= 1.5.2-1+deb11u1) >+,golang-github-containers-storage-dev (>= 1.24.6+dfsg1-1+deb11u1) > >The updated golang-github-containers-storage-dev version there isn't >actually sufficient to ensure that the fixed version is picked up - you >want 1.24.*8*+dfsg1-1+deb11u1. > >At this point, either I can reject the current upload, and you can then >re-upload a fixed +deb11u1 or (possibly easier all around) you can >upload +deb11u2 as an incremental change on top of +deb11u1 which >simply fixes the dependency version. > >Regards, > >Adam > > -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#1034039: bullseye-pu: package libpod/3.0.1+dfsg1-3+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: lib...@packages.debian.org, siret...@tauware.de
Control: affects -1 + src:libpod
[ Reason ]
This code change picks up code changes in golang-github-containers-psgo
and golang-github-containers-storage to fix CVE-2022-1227. This is reported
as 1020907. This addresses a priviledge escalation issue when using
'podman top'. Upstream has more information in this issue in
https://bugzilla.redhat.com/show_bug.cgi?id=2070368
Additionally, another upstream code change is being backported to address
CVE-2022-27649. This is reported as #1020906. This is to address a
capability escalation issue on file descriptors that were not intended
to have inheritable capabilities.
[ Impact ]
Without this update, users remain vulnerable to the issues explained above.
[ Tests ]
I've manually built and installed the built package in a kvm virtual machine
and conducted some basic tests.
[ Risks ]
All patches have been cherry picked from the branches that redhat also
includes in RHEL.
[ 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 ]
diff --git a/debian/changelog b/debian/changelog
index 12a2268bb..dbd215727 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+libpod (3.0.1+dfsg1-3+deb11u2) bullseye; urgency=medium
+
+ * CVE-2022-1227: pickup changes in containers/psgo, Closes: #1020907
+ * CVE-2022-27649: do not set the inheritable capabilities, Closes: #1020906
+
+ -- Reinhard Tartler Wed, 05 Apr 2023 21:00:36 -0400
+
libpod (3.0.1+dfsg1-3+deb11u1) bullseye; urgency=medium
* Rebuild against containers-common to pickup seccomp updates required
diff --git a/debian/control b/debian/control
index 3df797b30..a8834b883 100644
--- a/debian/control
+++ b/debian/control
@@ -21,8 +21,8 @@ Build-Depends: debhelper-compat (= 12)
,golang-github-containers-common-dev (>= 0.33.4+ds1-1+deb11u1)
,golang-github-containers-image-dev (>= 5.10.2)
,golang-github-containers-ocicrypt-dev
-,golang-github-containers-psgo-dev
-,golang-github-containers-storage-dev (>= 1.24.6)
+,golang-github-containers-psgo-dev (>= 1.5.2-1+deb11u1)
+,golang-github-containers-storage-dev (>= 1.24.6+dfsg1-1+deb11u1)
,golang-github-coreos-bbolt-dev (>= 1.3.3~)
,golang-github-coreos-go-iptables-dev (>= 0.4.2~)
,golang-github-coreos-go-systemd-dev (>= 20~)
diff --git a/debian/patches/0001-do-not-set-the-inheritable-capabilities.patch
b/debian/patches/0001-do-not-set-the-inheritable-capabilities.patch
new file mode 100644
index 0..3d7666b91
--- /dev/null
+++ b/debian/patches/0001-do-not-set-the-inheritable-capabilities.patch
@@ -0,0 +1,109 @@
+From d2848c0281ed94992c4b23c5899e36afc1af Mon Sep 17 00:00:00 2001
+From: Andre Moreira Magalhaes
+Date: Mon, 19 Sep 2022 11:03:21 -0300
+Subject: [PATCH] do not set the inheritable capabilities
+
+The kernel never sets the inheritable capabilities for a process, they
+are only set by userspace. Emulate the same behavior.
+
+Closes: CVE-2022-27649
+
+(backported from upstream commit 7b368768c2990b9781b2b6813e1c7f91c7e6cb13)
+---
+ libpod/oci_conmon_linux.go | 7 +--
+ pkg/specgen/generate/security.go | 7 +--
+ test/e2e/run_test.go | 6 +++---
+ 3 files changed, 13 insertions(+), 7 deletions(-)
+
+diff --git a/libpod/oci_conmon_linux.go b/libpod/oci_conmon_linux.go
+index 38ffba7d2..b073feee1 100644
+--- a/libpod/oci_conmon_linux.go
b/libpod/oci_conmon_linux.go
+@@ -1281,11 +1281,14 @@ func prepareProcessExec(c *Container, options
*ExecOptions, env []string, sessio
+ } else {
+ pspec.Capabilities.Bounding =
ctrSpec.Process.Capabilities.Bounding
+ }
++
++ // Always unset the inheritable capabilities similarly to what the
Linux kernel does
++ // They are used only when using capabilities with uid != 0.
++ pspec.Capabilities.Inheritable = []string{}
++
+ if execUser.Uid == 0 {
+ pspec.Capabilities.Effective = pspec.Capabilities.Bounding
+- pspec.Capabilities.Inheritable = pspec.Capabilities.Bounding
+ pspec.Capabilities.Permitted = pspec.Capabilities.Bounding
+- pspec.Capabilities.Ambient = pspec.Capabilities.Bounding
+ } else {
+ if user == c.config.User {
+ pspec.Capabilities.Effective =
ctrSpec.Process.Capabilities.Effective
+diff --git a/pkg/specgen/generate/security.go
b/pkg/specgen/generate/security.go
+index fb45d87db..c18f83217 100644
+--- a/pkg/specgen/generate/security.go
b/pkg/specgen/generate/security.go
+@@ -130,6 +130,10 @@ func securityConfigureGenerator(s *specgen.SpecGenerator,
g *generate.Generator,
+
+
Bug#1027257: bullseye-pu: package golang-github-containers-storage/1.24.8+dfsg1-2~deb11u1
Control: tag -1 -moreinfo
On 4/1/23 7:04 PM, Reinhard Tartler wrote:
On 4/1/23 3:51 PM, Adam D. Barratt wrote:
Control: tags -1 + moreinfo
Apologies for the delay in getting back to you on this.
On Wed, 2022-12-28 at 22:26 -0500, Reinhard Tartler wrote:
In order to fix CVE-2022-1227, an update to golang-github-containers-
psgo
is needed, more specifically,
https://github.com/containers/psgo/pull/92
That patch introduces a dependency on golang-github-containers-
storage, and uses
the helper functions RawTo{Container,Host} which are introduced with
this patch.
[...]
The code changes adds a helper function that isn't used otherwise
yet.
Looking at the diff, it appears that what it actually does is rename
two existing helper functions, with no functional change to either. Am
I missing something?
You are correct. The patch renames the helper functions to an Uppercase
spelling.
This exposes the function to other packages, which is being used in the patch
to fix CVE-2022-1227.
I would recommend approving this code change.
+golang-github-containers-storage (1.24.8+dfsg1-2~deb11u1) bullseye;
urgency=medium
Given what I can see of the package's upload history, the version
should rather be 1.24.8+dfsg1-1+deb11u1.
Will do!
Updated debdiff attached to this email.
Okay to upload now?
-rtdiff -Nru golang-github-containers-storage-1.24.8+dfsg1/debian/changelog
golang-github-containers-storage-1.24.8+dfsg1/debian/changelog
--- golang-github-containers-storage-1.24.8+dfsg1/debian/changelog
2021-02-21 14:40:55.0 -0500
+++ golang-github-containers-storage-1.24.8+dfsg1/debian/changelog
2022-12-28 21:39:17.0 -0500
@@ -1,3 +1,12 @@
+golang-github-containers-storage (1.24.8+dfsg1-1+deb11u1) bullseye;
urgency=medium
+
+ [ Vignesh Raman ]
+ * prereq to fix CVE-2022-1227: pkg: idtools: export RawTo{Container,Host}:
+makes previously internal functions publicly accessible, which is being
+used by later versions of golang-github-containers-psgo.
+
+ -- Reinhard Tartler Wed, 28 Dec 2022 21:39:17 -0500
+
golang-github-containers-storage (1.24.8+dfsg1-1) unstable; urgency=medium
* New upstream release, focused on targetted bugfixes for podman 3.0
diff -Nru
golang-github-containers-storage-1.24.8+dfsg1/debian/patches/0001-pkg-idtools-export-RawTo-Container-Host.patch
golang-github-containers-storage-1.24.8+dfsg1/debian/patches/0001-pkg-idtools-export-RawTo-Container-Host.patch
---
golang-github-containers-storage-1.24.8+dfsg1/debian/patches/0001-pkg-idtools-export-RawTo-Container-Host.patch
1969-12-31 19:00:00.0 -0500
+++
golang-github-containers-storage-1.24.8+dfsg1/debian/patches/0001-pkg-idtools-export-RawTo-Container-Host.patch
2022-12-28 21:39:17.0 -0500
@@ -0,0 +1,111 @@
+From 3da85a122411a57b5a65dc243ae56f89d7fd2564 Mon Sep 17 00:00:00 2001
+From: Aleksa Sarai
+Date: Wed, 12 Jan 2022 12:56:56 +1100
+Subject: [PATCH 1/4] pkg: idtools: export RawTo{Container,Host}
+
+While the IDMapping methods are preferable for most users, sometimes it
+is necessary to map a single ID using a given mapping. In particular
+this is needed for psgo to be able to map the user and group entries in
+/proc/$pid/status using the user namespace of the target process.
+
+Required to resolve CVE-2022-1227.
+
+Signed-off-by: Aleksa Sarai
+Backported-by: Valentin Rothberg
+---
+ pkg/idtools/idtools.go | 36 ++--
+ 1 file changed, 22 insertions(+), 14 deletions(-)
+
+diff --git a/pkg/idtools/idtools.go b/pkg/idtools/idtools.go
+index 83bc8c34f..d3d56066e 100644
+--- a/pkg/idtools/idtools.go
b/pkg/idtools/idtools.go
+@@ -82,7 +82,7 @@ func GetRootUIDGID(uidMap, gidMap []IDMap) (int, int, error)
{
+ if len(uidMap) == 1 && uidMap[0].Size == 1 {
+ uid = uidMap[0].HostID
+ } else {
+- uid, err = toHost(0, uidMap)
++ uid, err = RawToHost(0, uidMap)
+ if err != nil {
+ return -1, -1, err
+ }
+@@ -90,7 +90,7 @@ func GetRootUIDGID(uidMap, gidMap []IDMap) (int, int, error)
{
+ if len(gidMap) == 1 && gidMap[0].Size == 1 {
+ gid = gidMap[0].HostID
+ } else {
+- gid, err = toHost(0, gidMap)
++ gid, err = RawToHost(0, gidMap)
+ if err != nil {
+ return -1, -1, err
+ }
+@@ -98,10 +98,14 @@ func GetRootUIDGID(uidMap, gidMap []IDMap) (int, int,
error) {
+ return uid, gid, nil
+ }
+
+-// toContainer takes an id mapping, and uses it to translate a
+-// host ID to the remapped ID. If no map is provided, then the translation
+-// assumes a 1-to-1 mapping and returns the passed in id
+-func toContainer(hostID int, idMap []IDMap) (int, error) {
++// RawToContainer takes an id mapping, and uses it to translate a host ID to
++// the remapped ID. If no map is provided, then the translation assumes a
++// 1-to-1 map
Bug#1027257: bullseye-pu: package golang-github-containers-storage/1.24.8+dfsg1-2~deb11u1
On 4/1/23 3:51 PM, Adam D. Barratt wrote:
Control: tags -1 + moreinfo
Apologies for the delay in getting back to you on this.
On Wed, 2022-12-28 at 22:26 -0500, Reinhard Tartler wrote:
In order to fix CVE-2022-1227, an update to golang-github-containers-
psgo
is needed, more specifically,
https://github.com/containers/psgo/pull/92
That patch introduces a dependency on golang-github-containers-
storage, and uses
the helper functions RawTo{Container,Host} which are introduced with
this patch.
[...]
The code changes adds a helper function that isn't used otherwise
yet.
Looking at the diff, it appears that what it actually does is rename
two existing helper functions, with no functional change to either. Am
I missing something?
You are correct. The patch renames the helper functions to an Uppercase
spelling.
This exposes the function to other packages, which is being used in the patch
to fix CVE-2022-1227.
I would recommend approving this code change.
+golang-github-containers-storage (1.24.8+dfsg1-2~deb11u1) bullseye;
urgency=medium
Given what I can see of the package's upload history, the version
should rather be 1.24.8+dfsg1-1+deb11u1.
Will do!
-rt
Bug#1031097: bullseye-pu: package conmon/2.0.25+ds1-1.1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: con...@packages.debian.org, Dan Nicholson
Control: affects -1 + src:conmon
[ Reason ]
conmon 2.0.25 contains a bug where the container will hang when there
is lots of terminal output. You can easily reproduce like so:
podman run -it --rm debian:latest
find /
This is fixed in 2.0.26 with
https://github.com/containers/conmon/commit/2b873145a85a212f703c9c00db13717ab0204318.
See https://github.com/containers/conmon/issues/236.
[ Impact ]
podman hangs with the testcase above
[ Tests ]
no automated test case
[ Risks ]
this is a one-line code-change backported from upstream
[ 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 ]
diff --git a/src/conn_sock.c b/src/conn_sock.c
index e569113f..02aee701 100644
--- a/src/conn_sock.c
+++ b/src/conn_sock.c
@@ -280,7 +280,6 @@ static gboolean attach_cb(int fd, G_GNUC_UNUSED
GIOCondition condition, gpointer
pexit("Failed to allocate memory");
}
init_remote_sock(remote_sock, srcsock);
- g_unix_set_fd_nonblocking(new_fd, TRUE, NULL);
remote_sock->fd = new_fd;
g_unix_fd_add(remote_sock->fd, G_IO_IN | G_IO_HUP | G_IO_ERR,
remote_sock_cb, remote_sock);
g_ptr_array_add(remote_sock->dest->readers, remote_sock);
[ Other info ]
See https://github.com/containers/conmon/issues/236 for the full investigation
diff -Nru conmon-2.0.25+ds1/debian/changelog conmon-2.0.25+ds1/debian/changelog
--- conmon-2.0.25+ds1/debian/changelog 2021-07-14 11:46:07.0 -0600
+++ conmon-2.0.25+ds1/debian/changelog 2022-06-29 09:35:38.0 -0600
@@ -1,3 +1,10 @@
+conmon (2.0.25+ds1-1.1+deb11u1) bullseye; urgency=medium
+
+ * Backport upstream fix to not hang when forwarding container
+stdout/stderr with lots of output. (Closes: #1014030)
+
+ -- Dan Nicholson Wed, 29 Jun 2022 09:35:38 -0600
+
conmon (2.0.25+ds1-1.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru
conmon-2.0.25+ds1/debian/patches/0002-conn_sock-do-not-fail-on-EAGAIN.patch
conmon-2.0.25+ds1/debian/patches/0002-conn_sock-do-not-fail-on-EAGAIN.patch
--- conmon-2.0.25+ds1/debian/patches/0002-conn_sock-do-not-fail-on-EAGAIN.patch
1969-12-31 17:00:00.0 -0700
+++ conmon-2.0.25+ds1/debian/patches/0002-conn_sock-do-not-fail-on-EAGAIN.patch
2022-06-29 09:33:10.0 -0600
@@ -0,0 +1,37 @@
+From 2b873145a85a212f703c9c00db13717ab0204318 Mon Sep 17 00:00:00 2001
+From: Giuseppe Scrivano
+Date: Tue, 2 Feb 2021 11:35:39 +0100
+Subject: [PATCH] conn_sock: do not fail on EAGAIN
+
+commit 6287bd884d9bf29e76ac877e0c7e6aad04bc24a4 introduced the
+regression.
+
+writes to the attached sockets must be blocking, otherwise the
+write_back_to_remote_consoles() shutdowns the socket when write fails
+with EAGAIN.
+
+I've verified the original issue fixed with commit 62887bd is not
+reintroduced with this patch.
+
+Closes: https://github.com/containers/conmon/issues/236
+
+Signed-off-by: Giuseppe Scrivano
+---
+ src/conn_sock.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/src/conn_sock.c b/src/conn_sock.c
+index e569113..02aee70 100644
+--- a/src/conn_sock.c
b/src/conn_sock.c
+@@ -280,7 +280,6 @@ static gboolean attach_cb(int fd, G_GNUC_UNUSED
GIOCondition condition, gpointer
+ pexit("Failed to allocate memory");
+ }
+ init_remote_sock(remote_sock, srcsock);
+- g_unix_set_fd_nonblocking(new_fd, TRUE, NULL);
+ remote_sock->fd = new_fd;
+ g_unix_fd_add(remote_sock->fd, G_IO_IN | G_IO_HUP | G_IO_ERR,
remote_sock_cb, remote_sock);
+ g_ptr_array_add(remote_sock->dest->readers, remote_sock);
+--
+2.30.2
+
diff -Nru conmon-2.0.25+ds1/debian/patches/series
conmon-2.0.25+ds1/debian/patches/series
--- conmon-2.0.25+ds1/debian/patches/series 2021-07-14 11:46:07.0
-0600
+++ conmon-2.0.25+ds1/debian/patches/series 2022-06-29 09:33:10.0
-0600
@@ -1 +1,2 @@
0001-Reset-OOM-score-back-to-0-for-container-runtime.patch
+0002-conn_sock-do-not-fail-on-EAGAIN.patch
Bug#1027258: bullseye-pu: package golang-github-containers-psgo/1.5.2-2~deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: golang-github-containers-p...@packages.debian.org,
siret...@tauware.de, siret...@gmail.com, Vignesh Raman
vignesh.ra...@collabora.com
Control: affects -1 + src:golang-github-containers-psgo
[ Reason ]
Backport for CVE-2022-1227, taken from
https://github.com/containers/psgo/pull/92
This prevents an exploit when running 'podman top'
[ Impact ]
[ Tests ]
No new test is added. The code change is rather small and straight-forward to
review. It required small changes to apply to this older version.
[ Risks ]
I determined that the code change and adaptions to version 1.5.2 is easier to
review than updating containers-psgo to upstream version 1.7.2, which would
be closer to how upstream or Fedora/RedHat would recommend to address this
issue.
[ 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 ]
diff --git a/debian/changelog b/debian/changelog
index a1f0d96..0448fdf 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+golang-github-containers-psgo (1.5.2-2~deb11u1) bullseye; urgency=medium
+
+ * CVE-2022-1227: do not join the process user namespace
+
+ -- Reinhard Tartler Wed, 28 Dec 2022 21:21:57 -0500
+
golang-github-containers-psgo (1.5.2-1) unstable; urgency=medium
* Team upload
diff --git a/debian/control b/debian/control
index 5a52891..ba4c8e5 100644
--- a/debian/control
+++ b/debian/control
@@ -10,6 +10,7 @@ Build-Depends:
dh-golang,
Build-Depends-Indep:
golang-any,
+ golang-github-containers-storage-dev (>= 1.24.8+dfsg1-2~deb11u1),
golang-github-opencontainers-runc-dev,
golang-github-pkg-errors-dev,
golang-github-sirupsen-logrus-dev,
diff --git a/debian/patches/CVE-2022-1227.patch
b/debian/patches/CVE-2022-1227.patch
new file mode 100644
index 000..991a7c5
--- /dev/null
+++ b/debian/patches/CVE-2022-1227.patch
@@ -0,0 +1,279 @@
+commit 3ae3044916481f5c001f64a9d26110b878a676e0 (github/v1.7.1-fedora)
+Author: Aleksa Sarai
+Date: Wed Jan 12 01:01:30 2022 +1100
+
+internal: proc: do not join the process user namespace
+
+The only reason we joined the process user namespace was to map a
+handful of fields into the same usernamepsace as that process. This
+procedure can be implemented entirely in Go without having to run code
+inside the container.
+
+In addition, since psgo is used inside "podman top", we were actually
+executing the nsenter binary *from the container* without all of the
+container's security profiles applied. At the very least this would
+allow a container process to return bad data to psgo (possibly confusing
+management scripts using psgo) and at the very worst it would allow the
+container process to escalate privileges by getting podman to execute
+code without all of the container security profiles applied.
+
+Fixes: CVE-2022-1227
+
+Signed-off-by: Aleksa Sarai
+Backported-by: Valentin Rothberg
+Signed-off-by: Valentin Rothberg
+
+Index: golang-github-containers-psgo/internal/proc/ns.go
+===
+--- golang-github-containers-psgo.orig/internal/proc/ns.go
golang-github-containers-psgo/internal/proc/ns.go
+@@ -21,14 +21,9 @@ import (
+ "os"
+
+ "github.com/pkg/errors"
++ "github.com/containers/storage/pkg/idtools"
+ )
+
+-type IDMap struct {
+- ContainerID int
+- HostID int
+- Sizeint
+-}
+-
+ // ParsePIDNamespace returns the content of /proc/$pid/ns/pid.
+ func ParsePIDNamespace(pid string) (string, error) {
+ pidNS, err := os.Readlink(fmt.Sprintf("/proc/%s/ns/pid", pid))
+@@ -48,14 +43,14 @@ func ParseUserNamespace(pid string) (str
+ }
+
+ // ReadMappings reads the user namespace mappings at the specified path
+-func ReadMappings(path string) ([]IDMap, error) {
++func ReadMappings(path string) ([]idtools.IDMap, error) {
+ file, err := os.Open(path)
+ if err != nil {
+ return nil, errors.Wrapf(err, "cannot open %s", path)
+ }
+ defer file.Close()
+
+- mappings := []IDMap{}
++ var mappings []idtools.IDMap
+
+ buf := bufio.NewReader(file)
+ for {
+@@ -70,10 +65,10 @@ func ReadMappings(path string) ([]IDMap,
+ return mappings, nil
+ }
+
+- containerID, hostID, size := 0, 0, 0
++ var containerID, hostID, size int
+ if _, err := fmt.Sscanf(string(line), "%d %d %d", ,
, ); err != nil {
+ return nil, errors.Wrapf(err, "cannot parse %s",
string(line))
+ }
+- mappings = append(mappings, IDM
Bug#1027257: bullseye-pu: package golang-github-containers-storage/1.24.8+dfsg1-2~deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: golang-github-containers-stor...@packages.debian.org,
siret...@tauware.de, siret...@gmail.com, Vignesh Raman
vignesh.ra...@collabora.com
Control: affects -1 + src:golang-github-containers-storage
[ Reason ]
In order to fix CVE-2022-1227, an update to golang-github-containers-psgo
is needed, more specifically, https://github.com/containers/psgo/pull/92
That patch introduces a dependency on golang-github-containers-storage, and uses
the helper functions RawTo{Container,Host} which are introduced with this patch.
[ Impact ]
[ Tests ]
No new tests are added. The patch was taken from upstream and required
little modificaiton to apply.
[ Risks ]
The code changes adds a helper function that isn't used otherwise yet.
[ 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 ]
diff --git a/debian/changelog b/debian/changelog
index 837efeeb1..640a90134 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+golang-github-containers-storage (1.24.8+dfsg1-2~deb11u1) bullseye;
urgency=medium
+
+ [ Vignesh Raman ]
+ * prereq to fix CVE-2022-1227: pkg: idtools: export RawTo{Container,Host}
+
+ -- Reinhard Tartler Wed, 28 Dec 2022 21:39:17 -0500
+
golang-github-containers-storage (1.24.8+dfsg1-1) unstable; urgency=medium
* New upstream release, focused on targetted bugfixes for podman 3.0
diff --git a/debian/patches/0001-pkg-idtools-export-RawTo-Container-Host.patch
b/debian/patches/0001-pkg-idtools-export-RawTo-Container-Host.patch
new file mode 100644
index 0..d00cbd0e9
--- /dev/null
+++ b/debian/patches/0001-pkg-idtools-export-RawTo-Container-Host.patch
@@ -0,0 +1,111 @@
+From 3da85a122411a57b5a65dc243ae56f89d7fd2564 Mon Sep 17 00:00:00 2001
+From: Aleksa Sarai
+Date: Wed, 12 Jan 2022 12:56:56 +1100
+Subject: [PATCH 1/4] pkg: idtools: export RawTo{Container,Host}
+
+While the IDMapping methods are preferable for most users, sometimes it
+is necessary to map a single ID using a given mapping. In particular
+this is needed for psgo to be able to map the user and group entries in
+/proc/$pid/status using the user namespace of the target process.
+
+Required to resolve CVE-2022-1227.
+
+Signed-off-by: Aleksa Sarai
+Backported-by: Valentin Rothberg
+---
+ pkg/idtools/idtools.go | 36 ++--
+ 1 file changed, 22 insertions(+), 14 deletions(-)
+
+diff --git a/pkg/idtools/idtools.go b/pkg/idtools/idtools.go
+index 83bc8c34f..d3d56066e 100644
+--- a/pkg/idtools/idtools.go
b/pkg/idtools/idtools.go
+@@ -82,7 +82,7 @@ func GetRootUIDGID(uidMap, gidMap []IDMap) (int, int, error)
{
+ if len(uidMap) == 1 && uidMap[0].Size == 1 {
+ uid = uidMap[0].HostID
+ } else {
+- uid, err = toHost(0, uidMap)
++ uid, err = RawToHost(0, uidMap)
+ if err != nil {
+ return -1, -1, err
+ }
+@@ -90,7 +90,7 @@ func GetRootUIDGID(uidMap, gidMap []IDMap) (int, int, error)
{
+ if len(gidMap) == 1 && gidMap[0].Size == 1 {
+ gid = gidMap[0].HostID
+ } else {
+- gid, err = toHost(0, gidMap)
++ gid, err = RawToHost(0, gidMap)
+ if err != nil {
+ return -1, -1, err
+ }
+@@ -98,10 +98,14 @@ func GetRootUIDGID(uidMap, gidMap []IDMap) (int, int,
error) {
+ return uid, gid, nil
+ }
+
+-// toContainer takes an id mapping, and uses it to translate a
+-// host ID to the remapped ID. If no map is provided, then the translation
+-// assumes a 1-to-1 mapping and returns the passed in id
+-func toContainer(hostID int, idMap []IDMap) (int, error) {
++// RawToContainer takes an id mapping, and uses it to translate a host ID to
++// the remapped ID. If no map is provided, then the translation assumes a
++// 1-to-1 mapping and returns the passed in id.
++//
++// If you wish to map a (uid,gid) combination you should use the corresponding
++// IDMappings methods, which ensure that you are mapping the correct ID
against
++// the correct mapping.
++func RawToContainer(hostID int, idMap []IDMap) (int, error) {
+ if idMap == nil {
+ return hostID, nil
+ }
+@@ -114,10 +118,14 @@ func toContainer(hostID int, idMap []IDMap) (int, error)
{
+ return -1, fmt.Errorf("Host ID %d cannot be mapped to a container ID",
hostID)
+ }
+
+-// toHost takes an id mapping and a remapped ID, and translates the
+-// ID to the mapped host ID. If no map is provided, then the translation
+-// assumes a 1-to-1 mapping and returns the passed in id #
+-func toHost(contID int, idMap []IDMap) (int, error) {
++// RawToHost takes an id mapping and a remapped
Bug#1025401: unblock: libpod/4.3.1+ds1-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package libpod libpod needs to migrate together with: golang-github-containers-common_0.50.1+ds1-2 golang-github-containers-buildah_1.28.0+ds1-3 [ Reason ] There have been API changes that prevent the new libpod from building with old versions. Also, the old libpod doesn't build with new versions of -common and buildah. This was all successfully detected by autopkgtest. [ Tests ] I've manually scheduled autopkgtests on ci.debian.net to show that autopkgtests passes with these three packages in combination. hint libpod/4.3.1+ds1-5 golang-github-containers-common/0.50.1+ds1-2 golang-github-containers-buildah/1.28.0+ds1-3
Bug#1013349: release.debian.org: Please hint golang-github-openshift-imagebuilder and golang-github-containers-buildah into testing
Package: release.debian.org Severity: normal The following two packages need to go into testing together: golang-github-openshift-imagebuilder_1.2.3+ds1-1 golang-github-containers-buildah_1.23.1+ds1-3 golang-github-openshift-imagebuilder introduced some API changes that broke the compilation of libpod and golang-github-containers-buildah. I've backpoted a patch in golang-github-containers-buildah to address this which fixes the compilation also of libpod. This issue has been caught by autopkgtest. I've tried to schedule autopkgtests manually to verify that it addresses the issue, and it indeed does. However, britney doesn't seem to pick up these new results. Please hint these two packages manually so that the can go in together.
Bug#1012723: bullseye-pu: package runc/runc_1.0.0~rc93+ds1-5+deb11u1
On Tue, Jun 14, 2022 at 5:54 AM Emilio Pozuelo Monfort
wrote:
> On 13/06/2022 19:12, Adam D. Barratt wrote:
> > On Mon, 2022-06-13 at 10:55 +0800, Shengjing Zhu wrote:
> >> X-Debbugs-CC: siret...@debian.org, t...@security.debian.org
> >>
> >> Hi,
> >>
> >> On Sun, Jun 12, 2022 at 05:33:48PM -0400, Reinhard Tartler wrote:
> >>> diff -Nru runc-1.0.0~rc93+ds1/debian/changelog runc-
> >>> 1.0.0~rc93+ds1/debian/changelog
> >>> --- runc-1.0.0~rc93+ds1/debian/changelog2022-06-12
> >>> 14:49:36.0 -0400
> >>> +++ runc-1.0.0~rc93+ds1/debian/changelog2021-05-19
> >>> 14:46:14.0 -0400
> >>> @@ -1,10 +1,3 @@
> >>> -runc (1.0.0~rc93+ds1-5+deb11u1) bullseye; urgency=medium
> >>> -
> >>> - * Team upload.
> >>> - * backport upstream patch: Honor seccomp defaultErrnoRet,
> >>> Closes: #1012030
> >>> -
> >>> - -- Reinhard Tartler Sun, 12 Jun 2022
> >>> 14:49:36 -0400
> >>> -
> >>
> >> Could you include the patch for CVE-2022-29162?
> >>
> >> https://security-tracker.debian.org/tracker/CVE-2022-29162
> >>
> >> If you don't have time, I can work on this later in this week.
> >
> > The Security Tracker says it's not fixed in unstable - is that correct?
> > If so, that needs addressing first before it can be considered for p-u.
>
> The tracker is corrected now, the issue was fixed in 1.1.2.
>
>
Thanks, I've tested the new runc and concluded it works fine. The effective
(additional) security patch reads:
--- a/exec.go
+++ b/exec.go
@@ -193,7 +193,6 @@
if caps := context.StringSlice("cap"); len(caps) > 0 {
for _, c := range caps {
p.Capabilities.Bounding = append(p.Capabilities.Bounding, c)
- p.Capabilities.Inheritable = append(p.Capabilities.Inheritable, c)
p.Capabilities.Effective = append(p.Capabilities.Effective, c)
p.Capabilities.Permitted = append(p.Capabilities.Permitted, c)
p.Capabilities.Ambient = append(p.Capabilities.Ambient, c)
--- a/libcontainer/README.md
+++ b/libcontainer/README.md
@@ -92,22 +92,6 @@
"CAP_KILL",
"CAP_AUDIT_WRITE",
},
- Inheritable: []string{
- "CAP_CHOWN",
- "CAP_DAC_OVERRIDE",
- "CAP_FSETID",
- "CAP_FOWNER",
- "CAP_MKNOD",
- "CAP_NET_RAW",
- "CAP_SETGID",
- "CAP_SETUID",
- "CAP_SETFCAP",
- "CAP_SETPCAP",
- "CAP_NET_BIND_SERVICE",
- "CAP_SYS_CHROOT",
- "CAP_KILL",
- "CAP_AUDIT_WRITE",
- },
Permitted: []string{
"CAP_CHOWN",
"CAP_DAC_OVERRIDE",
--- a/libcontainer/integration/exec_test.go
+++ b/libcontainer/integration/exec_test.go
@@ -412,7 +412,6 @@
pconfig.Capabilities.Bounding = append(config.Capabilities.Bounding,
"CAP_NET_ADMIN")
pconfig.Capabilities.Permitted = append(config.Capabilities.Permitted,
"CAP_NET_ADMIN")
pconfig.Capabilities.Effective = append(config.Capabilities.Effective,
"CAP_NET_ADMIN")
- pconfig.Capabilities.Inheritable =
append(config.Capabilities.Inheritable, "CAP_NET_ADMIN")
err = container.Run()
ok(t, err)
@@ -1593,7 +1592,6 @@
pconfig2.Capabilities.Bounding = append(config.Capabilities.Bounding,
"CAP_SYS_ADMIN")
pconfig2.Capabilities.Permitted = append(config.Capabilities.Permitted,
"CAP_SYS_ADMIN")
pconfig2.Capabilities.Effective = append(config.Capabilities.Effective,
"CAP_SYS_ADMIN")
- pconfig2.Capabilities.Inheritable =
append(config.Capabilities.Inheritable, "CAP_SYS_ADMIN")
err = container.Run(pconfig2)
stdinR2.Close()
--- a/libcontainer/integration/template_test.go
+++ b/libcontainer/integration/template_test.go
@@ -69,22 +69,6 @@
"CAP_KILL",
"CAP_AUDIT_WRITE",
},
- Inheritable: []string{
- "CAP_CHOWN",
- "CAP_DAC_OVERRIDE",
- "CAP_FSETID",
- "CAP_FOWNER",
- "CAP_MKNOD",
- "CAP_NET_RAW",
- "CAP_SETGID",
- "CAP_SETUID",
- "CAP_SETFCAP",
- "CAP_SETPCAP",
- "CAP_NET_BIND_SERVICE",
- "CAP_SYS_CHROOT",
- "CAP_KILL",
- "CAP_AUDIT_WRITE",
- },
Ambient: []string{
"CAP_CHOWN",
"CAP_DAC_OVERRIDE",
--- a/libcontainer/specconv/example.go
+++ b/libcontainer/specconv/example.go
@@ -41,11 +41,6 @@
"CAP_KILL",
"CAP_NET_BIND_SERVICE",
},
- Inheritable: []string{
- "CAP_AUDIT_WRITE",
- "CAP_KILL",
- "CAP_NET_BIND_SERVICE",
- },
Ambient: []string{
"CAP_AUDIT_WRITE",
"CAP_KILL",
Full updated debdiff attached to this email
--
regards,
Reinhard
runc_1.0.0~rc93+ds1-5+deb11u2.debdiff
Description: Binary data
Bug#1012723: bullseye-pu: package runc/runc_1.0.0~rc93+ds1-5+deb11u1
On Sun, Jun 12, 2022 at 10:57 PM Shengjing Zhu wrote: > X-Dbackport: do not set inheritable capabilities, Fixes: > CVE-2022-29162ebbugs-CC: siret...@debian.org, t...@security.debian.org > > Hi, > > On Sun, Jun 12, 2022 at 05:33:48PM -0400, Reinhard Tartler wrote: > > diff -Nru runc-1.0.0~rc93+ds1/debian/changelog > runc-1.0.0~rc93+ds1/debian/changelog > > --- runc-1.0.0~rc93+ds1/debian/changelog 2022-06-12 > 14:49:36.0 -0400 > > +++ runc-1.0.0~rc93+ds1/debian/changelog 2021-05-19 > 14:46:14.0 -0400 > > @@ -1,10 +1,3 @@ > > -runc (1.0.0~rc93+ds1-5+deb11u1) bullseye; urgency=medium > > - > > - * Team upload. > > - * backport upstream patch: Honor seccomp defaultErrnoRet, Closes: > #1012030 > > - > > - -- Reinhard Tartler Sun, 12 Jun 2022 14:49:36 > -0400 > > - > > Could you include the patch for CVE-2022-29162? > > https://security-tracker.debian.org/tracker/CVE-2022-29162 > > If you don't have time, I can work on this later in this week. > > backported as https://salsa.debian.org/go-team/packages/runc/-/commit/05b0597cb4db36f70c3bf737c87466a740a9eadf -- builds fine (and thus passes unit tests), still need to test it on a real machine. Thanks for pointing me to it! -rt -- regards, Reinhard
Bug#1012723: bullseye-pu: package runc/runc_1.0.0~rc93+ds1-5+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
In a recent stable update to podman changes to the seccomp filter where
introduced to allow podman to work with glibc found in bookwork See #994451,
#1006138. That update was successful in the sense it allows to run such
containers in the default configuration.
What was overlooked is that podman can run with two competing container runtime
engines: runc and crun. In bullseye, the default runtime is crun, and works
with the updates. However, some users prefer to run with runc, which is the
default in bookworm (and used by docker), which is currently broken (unless one
disables seccomp filtering completely). See #1012030 for full context,
[ Impact ]
This update backports a necessary upstream patch to allow podman to run with
runc in stable again. Without it, users need to make sure to use crun, or
disable seccomp filtering
[ Tests ]
There are unit tests and manual functional tests.
[ Risks ]
The functional change is small and easy to review. The majority of changes are
from updates to the unit 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 ]
This is the functional code change:
--- a/libcontainer/configs/config.go
+++ b/libcontainer/configs/config.go
@@ -31,9 +31,10 @@
// for syscalls. Additional architectures can be added by specifying them in
// Architectures.
type Seccomp struct {
- DefaultAction Action `json:"default_action"`
- Architectures []string `json:"architectures"`
- Syscalls []*Syscall `json:"syscalls"`
+ DefaultAction Action `json:"default_action"`
+ Architectures []string `json:"architectures"`
+ Syscalls[]*Syscall `json:"syscalls"`
+ DefaultErrnoRet *uint `json:"default_errno_ret"`
}
// Action is taken upon rule match in Seccomp
--- a/libcontainer/seccomp/patchbpf/enosys_linux.go
+++ b/libcontainer/seccomp/patchbpf/enosys_linux.go
@@ -523,6 +523,11 @@
}
func generatePatch(config *configs.Seccomp) ([]bpf.Instruction, error) {
+ // Patch the generated cBPF only when there is not a defaultErrnoRet set
+ // and it is different from ENOSYS
+ if config.DefaultErrnoRet != nil && *config.DefaultErrnoRet ==
uint(retErrnoEnosys) {
+ return nil, nil
+ }
// We only add the stub if the default action is not permissive.
if isAllowAction(config.DefaultAction) {
logrus.Debugf("seccomp: skipping -ENOSYS stub filter
generation")
--- a/libcontainer/seccomp/seccomp_linux.go
+++ b/libcontainer/seccomp/seccomp_linux.go
@@ -39,7 +39,7 @@
return errors.New("cannot initialize Seccomp - nil config
passed")
}
- defaultAction, err := getAction(config.DefaultAction, nil)
+ defaultAction, err := getAction(config.DefaultAction,
config.DefaultErrnoRet)
if err != nil {
return errors.New("error initializing seccomp - invalid default
action")
}
--- a/libcontainer/specconv/spec_linux.go
+++ b/libcontainer/specconv/spec_linux.go
@@ -872,6 +872,7 @@
return nil, err
}
newConfig.DefaultAction = newDefaultAction
+ newConfig.DefaultErrnoRet = config.DefaultErrnoRet
// Loop through all syscall blocks and convert them to libcontainer
format
for _, call := range config.Syscalls {
[ Other info ]
full debdiff attached
diff -Nru runc-1.0.0~rc93+ds1/debian/changelog
runc-1.0.0~rc93+ds1/debian/changelog
--- runc-1.0.0~rc93+ds1/debian/changelog2022-06-12 14:49:36.0
-0400
+++ runc-1.0.0~rc93+ds1/debian/changelog2021-05-19 14:46:14.0
-0400
@@ -1,10 +1,3 @@
-runc (1.0.0~rc93+ds1-5+deb11u1) bullseye; urgency=medium
-
- * Team upload.
- * backport upstream patch: Honor seccomp defaultErrnoRet, Closes: #1012030
-
- -- Reinhard Tartler Sun, 12 Jun 2022 14:49:36 -0400
-
runc (1.0.0~rc93+ds1-5) unstable; urgency=high
* Team upload.
diff -Nru runc-1.0.0~rc93+ds1/debian/patches/default_retno.patch
runc-1.0.0~rc93+ds1/debian/patches/default_retno.patch
--- runc-1.0.0~rc93+ds1/debian/patches/default_retno.patch 2022-06-12
14:49:36.0 -0400
+++ runc-1.0.0~rc93+ds1/debian/patches/default_retno.patch 1969-12-31
19:00:00.0 -0500
@@ -1,459 +0,0 @@
-commit c61f6062547d20b80a07e9593e9617e115773b28
-Author: Giuseppe Scrivano
-Date: Fri May 14 10:58:16 2021 +0200
-
-libcontainer: honor seccomp defaultErrnoRet
-
-https://github.com/opencontainers/runtime-spec/pull/1087 added support
-for defaultErrnoRet to the OCI runtime specs.
-
-If a defaultErrno
Bug#1004533: bullseye-pu: package golang-github-opencontainers-specs/1.0.2.41.g7413a7f-1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: siret...@tauware.de
[ Reason ]
podman (produced by src:libpod) allows users to run docker-compatible
container images. Because of recent changes in syscall wrappers, the version
of podman in bullseye will not be able to run container images that ship
glibc 2.34, which is currently in experimental and present in recent versions
of ubuntu and fedora.
[ Impact ]
Without these patches, containers will crash at least on arm (cf. #994451) and
amd64 at runtime.
[ Tests ]
The changes have been verified with manual testing.
[ Risks ]
I've attempted to keep the changes as minimal as possible.
[ 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 ]
There are three packages that need updating in order:
diff --git a/debian/changelog b/debian/changelog
index f644f7e..d06dbd5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+golang-github-opencontainers-specs (1.0.2.41.g7413a7f-1+deb11u1) bullseye;
urgency=medium
+
+ * Backport seccomp patches from upstream to allow execution of newer
+syscalls, Closes: #994451
+
+ -- Reinhard Tartler Mon, 27 Sep 2021 12:12:47 -0400
+
golang-github-opencontainers-specs (1.0.2.41.g7413a7f-1) unstable;
urgency=medium
* Team upload.
diff --git a/debian/patches/override-default-errno-code.patch
b/debian/patches/override-default-errno-code.patch
new file mode 100644
index 000..de4f589
--- /dev/null
+++ b/debian/patches/override-default-errno-code.patch
@@ -0,0 +1,66 @@
+From f7ef278d1bbaa6f97b8ef511fad478a31e953290 Mon Sep 17 00:00:00 2001
+From: Giuseppe Scrivano
+Date: Thu, 21 Jan 2021 13:20:57 +0100
+Subject: [PATCH] seccomp: allow to override default errno return code
+
+the specs already support overriding the errno code for the syscalls
+but the default value is hardcoded to EPERM.
+
+Add a new attribute to override the default value.
+
+Signed-off-by: Giuseppe Scrivano
+---
+ config-linux.md | 4
+ schema/config-linux.json | 3 +++
+ specs-go/config.go | 9 +
+ 3 files changed, 12 insertions(+), 4 deletions(-)
+
+diff --git a/config-linux.md b/config-linux.md
+index 3c9d77f5..9a515fbf 100644
+--- a/config-linux.md
b/config-linux.md
+@@ -594,6 +594,10 @@ The actions, architectures, and operators are strings
that match the definitions
+ The following parameters can be specified to set up seccomp:
+
+ * **`defaultAction`** *(string, REQUIRED)* - the default action for seccomp.
Allowed values are the same as `syscalls[].action`.
++* **`defaultErrnoRet`** *(uint, OPTIONAL)* - the errno return code to use.
++Some actions like `SCMP_ACT_ERRNO` and `SCMP_ACT_TRACE` allow to specify
the errno code to return.
++When the action doesn't support an errno, the runtime MUST print and
error and fail.
++If not specified then its default value is `EPERM`.
+ * **`architectures`** *(array of strings, OPTIONAL)* - the architecture used
for system calls.
+ A valid list of constants as of libseccomp v2.5.0 is shown below.
+
+diff --git a/schema/config-linux.json b/schema/config-linux.json
+index 83478cc9..61468b9c 100644
+--- a/schema/config-linux.json
b/schema/config-linux.json
+@@ -203,6 +203,9 @@
+ "defaultAction": {
+ "$ref": "defs-linux.json#/definitions/SeccompAction"
+ },
++"defaultErrnoRet": {
++"$ref": "defs.json#/definitions/uint32"
++},
+ "flags": {
+ "type": "array",
+ "items": {
+diff --git a/specs-go/config.go b/specs-go/config.go
+index 40955144..16eac6dd 100644
+--- a/specs-go/config.go
b/specs-go/config.go
+@@ -598,10 +598,11 @@ type VMImage struct {
+
+ // LinuxSeccomp represents syscall restrictions
+ type LinuxSeccomp struct {
+- DefaultAction LinuxSeccompAction `json:"defaultAction"`
+- Architectures []Arch `json:"architectures,omitempty"`
+- Flags []LinuxSeccompFlag `json:"flags,omitempty"`
+- Syscalls []LinuxSyscall `json:"syscalls,omitempty"`
++ DefaultAction LinuxSeccompAction `json:"defaultAction"`
++ DefaultErrnoRet *uint `json:"defaultErrnoRet,omitempty"`
++ Architectures []Arch `json:"architectures,omitempty"`
++ Flags []LinuxSeccompFlag `json:"flags,omitempty"`
++ Syscalls[]LinuxSyscall `json:"syscalls,omitempty"`
+ }
+
+ // Arch used for additional archit
Bug#995277: unblock: golang-github-klauspost-compress/1.11.7-2
Hi Paul, On Sun, Oct 3, 2021 at 12:39 PM Paul Gevers wrote: > Hi Reinhard, > > > The consistent OOM is surprising given that you state that the worker > > has 250GB of RAM. Looking at the logs, > > I note that the tests are being passed the option -p 160 by the > > dh-golang helper, so it will build > > and run test executables concurrently. That confirms to me that we are > > indeed running on these 250GB/160 core workers. > > We only have one armhf host, so *all* armhf tests are run there. I'm > also not seeing this problem back in the logs: > > https://ci.debian.net/munin/ci-worker-armel-01/ci-worker-armel-01/memory.html > . > But maybe the incident is too short to be caught by the once per 5 > minutes poll. > I think this might be the case. The whole package fails (or passes) usually in less than 5 minutes. These incidents would be very, very spiky. Probably something that captures the maximum values in the 5 minute interval would be more useful here. > Is it possible that armhf is setting up ulimits that limits the amount > > of memory the test may allocate? > > root@ci-worker-armel-01:~# ulimit > unlimited > > > As far as I understand, all golang packages use autodep8 to declare the > > tests, > > which doesn't support adding the Architecture field. > > I think you're right, but maybe we should fix autodep8 to enable the > change like the other overwrites in section `PACKAGE-SPECIFIC > CONFIGURATION` of $(man autodep8). > > > In order to get > > around this, > > I guess I could remove the Testsuite field from debian/control and add a > > debian/tests/control that looks similar to what autodep8 generates, but > adds > > the Architecture: !armhf restriction. > > Maybe until autodep8 is fixed? I fear that this may cause future trouble > if/when autodep8 support for golang gets updated. > Sure, I've cobbled up https://salsa.debian.org/ci-team/autodep8/-/merge_requests/25 for this. I've went ahead and implemented my limiting idea anyways: https://salsa.debian.org/go-team/packages/golang-github-klauspost-compress/-/commit/836de264a300e102a54055c1e3d629f82a1e8a1b Maybe Adrian is right and with too many goroutines going on at the same time, the test executable does exhaust the 3GB memory limitation on a 32bit architecture. debhelper has this convenient --max-parallel switch that I used in combination with setting GOMAXPROCS=8 to limit the number of goroutines in the test. the most recent test on armhf passes with no noticeable slowdown. Maybe we could go higher than 8, but finding out the optimal number does not seem like a good use of our time. Thanks for your help and input! -- regards, Reinhard
Bug#995277: unblock: golang-github-klauspost-compress/1.11.7-2
Hi Paul, thanks for getting back to me so quickly. Adding Nilesh and Shengjing, we were discussing this issue on a separate, private email conversation. On Wed, Sep 29, 2021 at 2:45 PM Paul Gevers wrote: > Hi Reinhard, > > On 29-09-2021 02:56, Reinhard Tartler wrote: > > Please unblock package golang-github-klauspost-compress > > > > The problem is with autopkgtest, on armel and armhf, the test > > machines frequently run out of memory when executing the extensive > > test suite. > > As our armhf worker has the most memory of all our workers (250GB) and > most cores (160), that would hint at an very bad bug on armhf/armel, or > bad parameters for e.g. xz (--threads=0 recently showed up as behaving > badly with 160 cores). > So, after some cleanups in the package and a backported patch from upstream that increases the test timeout from 2 to 4 minutes (and this consistently fixes failures on i386), we now have two runs in a row where the armhf builder OOM: https://ci.debian.net/data/autopkgtest/testing/armhf/g/golang-github-klauspost-compress/15714893/log.gz https://ci.debian.net/data/autopkgtest/testing/armhf/g/golang-github-klauspost-compress/15733957/log.gz Note that the test doesn't do xz, but zstd compression, cf. https://github.com/klauspost/compress/blob/master/zstd/README.md so your comment regarding --threads=0 does not seem to apply? -- not sure, please let me know what you think. The consistent OOM is surprising given that you state that the worker has 250GB of RAM. Looking at the logs, I note that the tests are being passed the option -p 160 by the dh-golang helper, so it will build and run test executables concurrently. That confirms to me that we are indeed running on these 250GB/160 core workers. Is it possible that armhf is setting up ulimits that limits the amount of memory the test may allocate? The thing is, I am able to pass the tests just fine on the on the porterbox abel.debian.org, which has significantly fewer cores (4) and memory (4GB). Maybe we need to limit the concurrent builds/test in debian/rules so that it never users more than let's say 8 cores or something? > > > I suggest the folling hints: > > > > force-badtest golang-github-klauspost-compress/*/armhf > > force-badtest golang-github-klauspost-compress/*/armel > > If it's just to have golang-github-klauspost-compress migrate, > force-skiptest would be better. But, as you want > golang-github-klauspost-compress itself to migrate, I rather have it > that you add an Architecture field to the test declaration and skip > armel and armhf. Flaky tests are considered RC. > As far as I understand, all golang packages use autodep8 to declare the tests, which doesn't support adding the Architecture field. In order to get around this, I guess I could remove the Testsuite field from debian/control and add a debian/tests/control that looks similar to what autodep8 generates, but adds the Architecture: !armhf restriction. Is that best practice or am I overlooking something? -- regards, Reinhard
Bug#995277: unblock: golang-github-klauspost-compress/1.11.7-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package golang-github-klauspost-compress The problem is with autopkgtest, on armel and armhf, the test machines frequently run out of memory when executing the extensive test suite. I suggest the folling hints: force-badtest golang-github-klauspost-compress/*/armhf force-badtest golang-github-klauspost-compress/*/armel (not sure what's the difference between /*/ and /all/ is). Thanks for your help!
Re: Bug#994451: golang-github-containers-common: secomp.json does not include newer syscall used by stable kernel/glibc on arm
User: release.debian@packages.debian.org Usertags: pu Tags: bullseye Severity: normal stop sorry for the abrupt ending of the previous mail. I'm attaching the debdiffs for the three uploads to this email. I'm happy to do the 3 uploads at any time. Please let me know what you think. On Mon, Sep 27, 2021 at 12:08 PM Reinhard Tartler wrote: > > On Thu, Sep 16, 2021 at 4:18 AM Bastien Roucariès < > roucaries.bast...@gmail.com> wrote: > >> Package: golang-github-containers-common >> Version: 0.33.4+ds1-1 >> Severity: critical >> Tags: upstream >> Forwarded: >> https://github.com/containers/common/commit/42d1db16bfc0dbaee5781d230dc2bcbaa0849c6e >> Control: fixed -1 0.42.1+ds1-1 >> >> Dear Maintainer, >> >> golang-github-containers-common in stable does not include recent syscall >> used >> by stable kernel/glibc breaking in my case simple container that do >> unattended- >> upgrade on arm >> particularly syscall=436 that is timer_settime64 >> >> I believe this should be fixed in a point release. >> > > I agree. I realized that these syscall changes also affect amd64. I was > able to reproduce the issue > by running a distribution that ships with glibc 2.34, such as ubuntu > impish. The testcase would be: > > $ podman run --rm -it ubuntu:impish sh -c 'apt update -qq && apt -y > full-upgrade && apt install -y libc6 jq' > > The symptom is described in more detail at > https://bugs.launchpad.net/ubuntu/+source/libpod/+bug/1943049 > > The problem here is that the issue is not simply dealt with updating the > secomp.json file, but also some code changes are required > that allow setting the default return value for some syscalls. This means > that in order to fix this issue in stable, 3 uploads are needed: > > - golang-github-opencontainers-specs > - golang-github-containers-common > - libpod > > I'm cloning this bug appropriately so that these uploads can be tracked > separately. > For now,I've backported and verified the changes. For your convenience, > I've uploaded the packages I got so far to > https://people.debian.org/~siretart/bug.994451/ > > >> BTW I strongly believe that seccomp.json is a config file and should be >> shipped in /etc and 988443 should also be shipped in stable. >> > > I could get convinced if the issue was fixable by just upading the > seccomp.json policy file. > Sadly, that's not the case. > > Stable Release team, I think this bug should be cloned with those > instructions: > > > -- > regards, > Reinhard > -- regards, Reinhard golang-github-opencontainers-specs.debdiff Description: Binary data golang-github-opencontainers-specs.debdiff Description: Binary data podman.debdiff Description: Binary data
Bug#993650: unblock: golang-github-openshift-imagebuilder/1.2.1+ds1-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Please hint golang-github-openshift-imagebuilder and golang-github-containers-storage to migrate to testing together The migration of golang-github-openshift-imagebuilder is blocked because it was built against the version of golang-github-containers-storage currently in unstable and therefore cannot migrate on its own. golang-github-containers-storage however can't migrate because it it triggers a failing autopkgtest on golang-github-openshift-imagebuilder: https://ci.debian.net/data/autopkgtest/testing/amd64/g/golang-github-openshift-imagebuilder/15026463/log.gz Inspection of the log shows that it misses a dependency that was added in the version of golang-github-openshift-imagebuilder currently in unstable. So golang-github-containers-storage technically breaks golang-github-openshift-imagebuilder in testing. I suggest to have both of them migrate together.
Bug#989899: unblock: libpod/3.0.1+dfsg1-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: debian...@lists.debian.org, siret...@debian.org
Please unblock package libpod/3.0.1+dfsg1-3
[ Reason ]
When using rootless podman, a major feature compared to docker.io,
non-trivial network configurations exhibit network connectivity
issues that manifest in 'Recv failure: Connection reset by peer' errors
This was reported and tracked in #989803, and upstream at
https://github.com/containers/podman/issues/9532
A minimal test-case for this issue is discussed at
https://stackoverflow.com/questions/67049585/how-to-publish-ports-in-user-defined-network-in-rootless-podman
I've identified the patch that was backported to podman 3.0 and 3.1, and
included it as a distribution patch.
[ Impact ]
Podman has two major modes of operation: running with root priviledges
(rootful, similar to docker), and rootless. This patch does not affect rootful
podman, but is limited to rootless podman where it has to setup appropriate
network namespaces and networking using slirp4netns.
[ Tests ]
Alexander Reichle-Schmehl was so good to manually build the package from source
and confirms that the issue is fixed,
cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989803#20
[ Risks ]
This is a leaf package, and therefore is very unlikely to affect other
packages. The patch is minimal, focus, and well-understood upstream.
For your reviewing convenience, you might find it easier to review the quilt
patch at
https://salsa.debian.org/debian/libpod/-/blob/master/debian/patches/networking-lookup-child-IP-in-networks.patch
Thank you for considering
unblock libpod/3.0.1+dfsg1-3
Full debdiff below:
siretart@x1:/srv/scratch/packages/containers/libpod$ git diff
debian/3.0.1+dfsg1-2
diff --git a/debian/changelog b/debian/changelog
index 7ec3e362d..88f7f1480 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+libpod (3.0.1+dfsg1-3) unstable; urgency=medium
+
+ * Add networking-lookup-child-IP-in-networks.patch, fixes rootless
+connection issue "Connection reset by peer", Closes: #989803
+
+ -- Reinhard Tartler Sun, 13 Jun 2021 18:28:49 -0400
+
libpod (3.0.1+dfsg1-2) unstable; urgency=medium
* Prefer crun over runc, Closes: #985379
diff --git a/debian/patches/networking-lookup-child-IP-in-networks.patch
b/debian/patches/networking-lookup-child-IP-in-networks.patch
new file mode 100644
index 0..d1444c0e6
--- /dev/null
+++ b/debian/patches/networking-lookup-child-IP-in-networks.patch
@@ -0,0 +1,83 @@
+commit 0ba1942f261158b9526310aac7ee5f183a109440
+Author: Giuseppe Scrivano
+Date: Fri Jan 22 13:54:24 2021 +0100
+
+networking: lookup child IP in networks
+
+if a CNI network is added to the container, use the IP address in that
+network instead of hard-coding the slirp4netns default.
+
+commit 5e65f0ba30f3fca73f8c207825632afef08378c1 introduced this
+regression.
+
+Closes: https://github.com/containers/podman/issues/9065
+
+Signed-off-by: Giuseppe Scrivano
+
+--- a/libpod/networking_linux.go
b/libpod/networking_linux.go
+@@ -559,13 +559,25 @@
+ }
+ }
+
++ childIP := slirp4netnsIP
++outer:
++ for _, r := range ctr.state.NetworkStatus {
++ for _, i := range r.IPs {
++ ipv4 := i.Address.IP.To4()
++ if ipv4 != nil {
++ childIP = ipv4.String()
++ break outer
++ }
++ }
++ }
++
+ cfg := rootlessport.Config{
+ Mappings: ctr.config.PortMappings,
+ NetNSPath: netnsPath,
+ ExitFD:3,
+ ReadyFD: 4,
+ TmpDir:ctr.runtime.config.Engine.TmpDir,
+- ChildIP: slirp4netnsIP,
++ ChildIP: childIP,
+ }
+ cfgJSON, err := json.Marshal(cfg)
+ if err != nil {
+--- a/test/system/500-networking.bats
b/test/system/500-networking.bats
+@@ -98,6 +98,7 @@
+ # "network create" now works rootless, with the help of a special container
+ @test "podman network create" {
+ skip_if_remote "FIXME: pending #7808"
++myport=54322
+
+ local mynetname=testnet-$(random_string 10)
+ local mysubnet=$(random_rfc1918_subnet)
+@@ -115,6 +116,27 @@
+ is "$output" ".* inet ${mysubnet}\.2/24 brd ${mysubnet}\.255 " \
+"sdfsdf"
+
++run_podman run --rm -d --network $mynetname -p 127.0.0.1:$myport:$myport \
++ $IMAGE nc -l -n -v -p $myport
++cid="$output"
++
++# emit random string, and check it
++teststring=$(random_string 30)
++echo "$teststring" | nc 127.0.0.1 $myport
++
++run_podman logs $cid
++# Sigh. We can't check line-by-line, because 'nc' output order is
++# unreliable. We usually get the 'connect to' l
Bug#987155: unblock: libpod/3.0.1+dfsg1-2
On 4/20/21 4:33 AM, Sebastian Ramacher wrote:
> What's the status of #987207? If that also requires changes in the
> package, it would be good to include them as well.
Indeed, turned out to be less severe, but I agree it's a good idea to pick it
up too.
I took the liberty of uploading this change to unstable, please consider
unblocking:
diff --git a/debian/changelog b/debian/changelog
index ec4748cb8..7ec3e362d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+libpod (3.0.1+dfsg1-2) unstable; urgency=medium
+
+ * Prefer crun over runc, Closes: #985379
+ * Add depends in iptables, Closes: #987207
+
+ -- Reinhard Tartler Wed, 21 Apr 2021 17:36:07 -0400
+
libpod (3.0.1+dfsg1-1) unstable; urgency=medium
* New upstream release
diff --git a/debian/control b/debian/control
index dedbb4462..d3865b0c1 100644
--- a/debian/control
+++ b/debian/control
@@ -94,7 +94,8 @@ Depends: ${misc:Depends}, ${shlibs:Depends}
,conmon (>= 2.0.18~)
,containernetworking-plugins (>= 0.8.7)
,golang-github-containers-common
-,runc (>= 1.0.0~rc92~) | crun
+,crun | runc (>= 1.0.0~rc92~)
+,iptables
Breaks: buildah (<< 1.10.1-6), slirp4netns (<< 0.4.1), fuse-overlayfs (<<
0.7.1)
Recommends: ${misc:Recommends}
,buildah (>= 1.10.1-6~)
Bug#987155: unblock: libpod/3.0.1+dfsg1-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: siret...@tauware.de, Filippo Giunchedi
Please unblock package libpod
Note that I have not uploaded the package yet, this is a pre-approval
request.
[ Reason ]
I as maintainer have missed an upstream change that switches the default
container runtime. The remedy is to switch the alternative dependency
in the podman binary pacakage package
[ Impact ]
Not granting the unblock request will leave an unfunctional default
configuration, please see https://bugs.debian.org/985379
[ Tests ]
This needs to be manually tested in a clean, freshly installed system,
such as a VM.
[ Risks ]
This patch does not contain a code-change, and is therefore low-risk.
As an alternative, this could be documented in the bullseye release-notes.
[ Checklist ]
[ ] 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
The patch would be this:
modified debian/control
@@ -94,7 +94,7 @@ Depends: ${misc:Depends}, ${shlibs:Depends}
,conmon (>= 2.0.18~)
,containernetworking-plugins (>= 0.8.7)
,golang-github-containers-common
-,runc (>= 1.0.0~rc92~) | crun
+,crun | runc (>= 1.0.0~rc92~)
Breaks: buildah (<< 1.10.1-6), slirp4netns (<< 0.4.1), fuse-overlayfs (<<
0.7.1)
Recommends: ${misc:Recommends}
,buildah (>= 1.10.1-6~)
unblock libpod/3.0.1+dfsg1-2
Bug#985822: unblock: slirp4netns/1.0.1-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package slirp4netns
Upstream author Akihiro Suda has reached out to me privately
about the slirp4netns package in Debian. Among others, he
(rightfully) pointed out that ipv6 is not working in the current
package due to an oversight. The remeidy is an easy to review pathc
[ Reason ]
Fix an oversight that restores ipv6
[ Impact ]
Users of podman, buildah, etc. that want to run rootless will get
unpleasently suprises when they try rootless networking that involves
ipv6
[ Tests ]
There are no automated tests
[ Risks ]
The patch seems trivial and safe. A non-functional slirp4netns has the
risk of breaking rootless podman.
unblock slirp4netns/1.0.1-2
diff --git a/debian/changelog b/debian/changelog
index 6f89392..20a2903 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+slirp4netns (1.0.1-2) unstable; urgency=medium
+
+ * Apply patch from upstrema to make ipv6 usable (Closes: #985780)
+
+ -- Reinhard Tartler Wed, 24 Mar 2021 07:43:48 -0400
+
slirp4netns (1.0.1-1) unstable; urgency=medium
* New upstream version 1.0.1
diff --git a/debian/patches/ipv6.patch b/debian/patches/ipv6.patch
new file mode 100644
index 000..f585f21
--- /dev/null
+++ b/debian/patches/ipv6.patch
@@ -0,0 +1,21 @@
+From 8d2aefecce7cca696f44d0792e196ecdd22072e4 Mon Sep 17 00:00:00 2001
+From: Ralf Haferkamp
+Date: Fri, 3 Jul 2020 11:35:52 +0200
+Subject: [PATCH] Fix config_from_options() to correctly enable ipv6
+
+Signed-off-by: Ralf Haferkamp
+---
+ main.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/main.c
b/main.c
+@@ -680,7 +680,7 @@
+ if (rc < 0) {
+ goto finish;
+ }
+-cfg->enable_ipv6 = cfg->enable_ipv6;
++cfg->enable_ipv6 = opt->enable_ipv6;
+ cfg->disable_host_loopback = opt->disable_host_loopback;
+ cfg->enable_sandbox = opt->enable_sandbox;
+ cfg->enable_seccomp = opt->enable_seccomp;
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..b5b92c7
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+ipv6.patch
Re: golang-github-revel-revel: Depends on network in tests
Got it. On Tue, Feb 16, 2021 at 4:03 PM Sebastian Ramacher wrote: > Control: severity -1 serious > > [...] > Tests are executed as part of the binary target: > > dh binary --no-act | grep auto_test >dh_auto_test > > So the "no required targets may attmept network access" rule applies. > Raising the severity accordingly. Please disable the tests that access > the network. > Thanks for getting back to me. I've just made a sourceful upload that disables the problematic test. -- regards, Reinhard
Re: golang-github-revel-revel: Depends on network in tests
Dear Golang Team, On Mon, Feb 15, 2021 at 1:23 PM Paul Gevers wrote: > On 15-02-2021 15:08, Reinhard Tartler wrote: > > Control: severity -1 important > > I agree with this. The Debian infra allows for use of the internet (if > not used to download programs, that's forbidden by ftp-master [1].) > [...] > > The package itself appears to be fine. The tests fail if and only if the > > test setup doesn't provide (proper) internet connectivity. In fact, it > > tries at test time to reach http://httpbin.org/get > > <http://httpbin.org/get> - a service aimed at developing and debugging > > programs that do HTTP/REST calls. > [...] > Please a the "needs-internet" restriction. It's there for this reason. > Your package seems to have never failed in testing, so, from the Debian > side of things, it looks you're fine. [...] > > 1) test that require internet to test if certain API's out there work > are fine *if* annotated with the needs-internet restriction. Personally, > I consider using on-line frameworks for that acceptable if the effort to > fake is high (that's often the case for maintainers in downstreams like > Debian) > 2) if possible, those tests should be in a separate autopkgtest > paragraph, such then when needs-internet tests are skipped (e.g. because > the infra doesn't provide access, like in Ubuntu) the rest of the tests > are still run. > This package doesn't (like most golang-packages) install a debian/tests/control file, but instead has a field 'Testsuite: autopkgtest-pkg-go' in debian/control instead. How to add the 'needs-internet' restriction to this testsuite? -- regards, Reinhard
golang-github-revel-revel: Depends on network in tests
Control: severity -1 important Dear release team, I'm writing as a member of the pkg-go team and am mostly concerned about potential removal of depending packages. The package itself appears to be fine. The tests fail if and only if the test setup doesn't provide (proper) internet connectivity. In fact, it tries at test time to reach http://httpbin.org/get - a service aimed at developing and debugging programs that do HTTP/REST calls. Based on this, I'm not convinced about removing a significant amount of packages from the buster release because of this issue. I'm therefore downgrading the issue to important and would recommend fixing it right after buster release. I'm reaching out to you to confirm this thinking. If you do believe this is something that ought to be fixed for buster, I'd be happy to upload the proposed patch to sid right away, as it seems appropriate to disable the test -- the additional test coverage that it could provide is in no relationship compared to the effort it would take to fake out the internet service. -- regards, Reinhard
Bug#982030: nmu: libpod_libpod
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu It seems that there is a problem with the image cache in podman 3.0-rc2, which turns out to be a bug in 'buildah'. I've uploaded a fix to unstable as golang-github-containers-buildah_1.19.3+dfsg1-2, but now we also need to get src:libpod rebuilt. nmu libpod_3.0.0~rc2+dfsg1-2 . ANY . unstable . -m 'Rebuild against golang-github-containers-buildah_1.19.3+dfsg1-2 to fix #981849' dw libpod_3.0.0~rc2+dfsg1-2 . ANY . -m 'golang-github-containers-buildah (>= 1.19.3+dfsg1-2)' Thanks! -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Re: Podman 3.0 and Debian bullseye
On Tue, Feb 2, 2021 at 3:01 PM Paul Gevers wrote: > Unfortunately I believe we're not really in the position to advise you > on the matter at hand as there are obviously pro's and con's for both > side which require detailed knowledge to balance them. It seems to me > that your having a decent discussion so we trust that you'll (together) > make the right choice, for the users and the release process. > Thanks for the feedback. Based on the productive (and constructive) discussion, and after reflecting on the matter for another night, I'm going to proceed with uploading the required packages. I'll also continue working with Dimtry, podman upstream and nomad upstream on finding a solution to get nomad-driver-podman into testing. Thanks to everyone who has participated in this discussion! Really looking forward to bullseye! -rt -- regards, Reinhard
Re: Podman 3.0 and Debian bullseye
On Tue, Feb 2, 2021 at 11:54 AM Adrian Bunk wrote: > On Sat, Jan 30, 2021 at 09:08:36PM -0500, Reinhard Tartler wrote: > >... > > On Mon, Jan 25, 2021 at 7:15 PM Dmitry Smirnov > wrote: > >... > > A low-effort workaround could be to add a build-dependency on podman to > > prevent > > it from building on mipsen. A better fix could be to patch podman to > build > > on > > mipsen... > >... > > The only code change in golang-github-containers-psgo 1.5.2 > seems to be a fix for a build issue affecting podman on mips, > this might be sufficient to fix building podman 3. > > After that fixing podman 2 on mips would require cherry-picking commits > > https://github.com/containers/podman/commit/1ad796677e1ce3f03463c791818176586987c389 > > https://github.com/containers/podman/commit/9dfc636fd613c5dac4717473ae2fd214f9835748 > > All of the above untested, but I can check that if someone does the > trivial golang-github-containers-psgo upgrade. > uploaded: https://tracker.debian.org/news/1227019/accepted-golang-github-containers-psgo-152-1-source-into-unstable/ Tests on mips appreciated. If you can, let me know if rootless podman works on mips! -rt -- regards, Reinhard
Re: Podman 3.0 and Debian bullseye
On Mon, Feb 1, 2021 at 4:58 PM Dmitry Smirnov wrote: > > > The fact that as has been mentioned in this thread a) bullseye is around > > the corner b) nomad-driver-podman isn't even in testing right now, c) > > podman itself is a much more popular package than nomad-driver-podman > > (or nomad for that matter), are all very strong points in favor of > > option (2), but are all *on top* of the original point -- again, IMHO. > > [...] > Also consider the discouragement factor. Me, maintainer of podman, nomad, > nomad-driver-podman as well as their countless dependency packages, > is at the verge of saying "whatever" and stop caring or even walk away > from the mess since the moment when technology become useless to me. > Too bad I've invested so much time stabilising it if "release concerns" > require me to break it... > > I'll think more about all this. Thank you for participating in a thoughtful and deliberate manner. I really appreciate it. Please rest assured that I do care about all users of 'testing' and 'unstable' a lot, and that's precisely why I've started this discussion thread. It is important to consider what are the tradeoffs at hand and what's the best interest for our users. In this case, I'm thinking about users of the upcoming "Debian/stable" release. They are going to use packages from this distribution this year and the years to come. Serving them with nomad as a simple and usable orchestrator surely sounds tempting. The thing is, this thread didn't convince me so far that nomad-driver-podman with the varlink interface provides as much value as I wish it had. I've even reached out to podman upstream to clarify their opinion. Basically, the workaround to avoid a container registry in the nomad-driver-podman package can be characterized as "inefficient" at best as podman would parse each and every layer in every OCI archive on every container start (at least in the 2.x implementation). Also, [1] makes me question whether this use-case is in scope of nomad upstream's intention. I'd also like to point out that while I agree that we should make every effort to not "break" our users of "testing"/"unstable", the setup remains a QA vehicle. It would be very limiting if we enforced this goal too strictly. Taking it to the extreme, it would prevent the release team from removing packages from 'testing' as even packages with severe bugs like grave security vulnerabilities still provides a lot of value to users that run their setups in an air-gapped environment. I'm a bit surprised that you feel being at the verge of saying "whatever" and giving up. The basic functionality you are asking for is already present, and just a matter of integrating into the package, a task that you have demonstrated to have significantly more skill than most other developers, me included. The specific setup that you are looking for is currently missing ind podman 3.0, but the workaround Valentin sketched at [2] really doesn't sound that hard to implement. Maybe you can look at it as "almost there" and find motivation in working with upstream on a solution that serves all nomad users rather than throwing in the towel? [1] https://github.com/hashicorp/nomad-driver-podman/issues/67#issuecomment-721042654 [2] https://github.com/containers/podman/issues/8927#issuecomment-762083962 -- regards, Reinhard
Re: Podman 3.0 and Debian bullseye
On Sat, Jan 30, 2021 at 10:33 PM Dmitry Smirnov wrote: > > > > No it hasn't... :( There is a serious regression: > > > https://github.com/hashicorp/nomad-driver-podman/issues/69 > > > > I'm having a hard time considering this a "serious" regression. The > problem > > as far as I understand is that while the driver does work fine with the > > new REST interface, it doesn't allow you to upload images in OCI format > > from local disk. > > If you instead chose to have imaged pulled from a (local) image registry, > > the driver would work fine. > > Do you have experience operating local container registry?? > I have and I can tell that it is not fun, to say the least. Docker registry > leaks disk space because it does not garbage collect some images... > Neither does it like Buildah/Podman's native image format, although it > can be remedied by building images with "export BUILDAH_FORMAT=docker". > > IMHO just saving built images to network share is the best, easiest, most > reliable way of deploying local images. It is the best to avoid Docker > registry whenever possible. > Have you considered keeping your NFS share with the OCI images, but using a registry just for distribution to your cluster? This way your registry is basically just a cache. Also, there may be alternatives to the official docker registry image. For instance, debian salsa offers team-specific container registries (built-in functionality for gitlab). For self-hosting solutions, maybe quay.io might be a better fit. On https://docs.projectquay.io/welcome.html you can find instructions for simple evaluation/developer setups as well as high-availability configurations (cf. https://docs.projectquay.io/deploy_quay_ha.html) > > Blocking podman 3.0 because of this is something I can't get behind. > > But maybe I'm missing something else here? > > I hope my answer above helps to understand the issue... > I can follow your thinking, and I sympathize, but ultimately, I still think that on the compromise between keeping varlink and podman at version 2.1, and updating to podman 3.0 and getting docker-compose functionality, Debian's users are better served by having podman 3.0 in bullseye. -- regards, Reinhard
Re: Podman 3.0 and Debian bullseye
trimming cc-list On Mon, Jan 25, 2021 at 7:15 PM Dmitry Smirnov wrote: > On Monday, 25 January 2021 10:47:25 PM AEDT Reinhard Tartler wrote: > > It seems that https://packages.qa.debian.org/n/nomad-driver-podman.html > > has never made it to testing, which makes me wonder whether > > it'll make it to bullseye. > > Nothing should stop it from getting to "testing". It was blocked on > due to "autopkgtest-pkg-go" which is useless for binary-only packages. > At a time I did not mind because I was not sure whether it is > good enough for "testing". > According to https://qa.debian.org/excuses.php?package=nomad-driver-podman the package won't migrate because of unsatisfiable dependencies on mips64el and mips64el. This is because the 'podman' package doesn't (currently) build on mipsen, whereas the nomad-driver-podman does. Apparently "britney" doesn't permit "partial" migrations... A low-effort workaround could be to add a build-dependency on podman to prevent it from building on mipsen. A better fix could be to patch podman to build on mipsen... > > Luckily it seems that issue > > has been fixed in latest master of nomad-driver-podman, cf. > > No it hasn't... :( There is a serious regression: > > https://github.com/hashicorp/nomad-driver-podman/issues/69 I'm having a hard time considering this a "serious" regression. The problem as far as I understand is that while the driver does work fine with the new REST interface, it doesn't allow you to upload images in OCI format from local disk. If you instead chose to have imaged pulled from a (local) image registry, the driver would work fine. Blocking podman 3.0 because of this is something I can't get behind. But maybe I'm missing something else here? -- regards, Reinhard
Re: Podman 3.0 and Debian bullseye
On Sat, Jan 30, 2021 at 5:03 PM Antonio Terceiro wrote: > FWIW I have been using podman 3.0.0~rc1 from experimental for a few days > and haven't noticed anything wrong with it. I hope we can have that > version in bullseye. > Me too. Dear release team, do you have any opinion on this topic? thanks, -rt -- regards, Reinhard
Re: Podman 3.0 and Debian bullseye
On Sun, Jan 24, 2021, 21:52 Dmitry Smirnov wrote: > On Monday, 25 January 2021 12:02:26 PM AEDT Reinhard Tartler wrote: > > - Podman 3 drops the legacy varlink interface. To the best of my > > knowledge, there are no packages in debian/testing that would require > > varlink (please correct me if I'm wrong here). Not having to support > > varlink in Debian seems a support benefit, there is little to no love > > for it upstream. > > Varlink is needed by Nomad/nomad-driver-podman. Unfortunately > "nomad-driver-podman" is not ready for new HTTP API due to some problems > with it (strangely enough Varlink interface is more mature at this point). > It seems that https://packages.qa.debian.org/n/nomad-driver-podman.html has never made it to testing, which makes me wonder whether it'll make it to bullseye. On the tradeoff "podman 3.0 with docker-compose" support vs. a "nomad driver for podman", I see more value for (more of) our users for the newer podman. I base that on popcon numbers: - nomand: 35 - nomad-driver-podman: 4 - podman: 340 > I'm running some of my infrastructure on "nomad-driver-podman" and loss > of Varlink is not acceptable to me until Podman and nomad-driver-podman > resolve some of the issues. I might happen soon, let's hope, but we > wouldn't > know until it happen... Ouch, that's indeed unfortunate. Luckily it seems that issue has been fixed in latest master of nomad-driver-podman, cf. https://github.com/hashicorp/nomad-driver-podman/commit/b580f2d1874273bd61640525d54a02e3747c2df4 https://github.com/hashicorp/nomad-driver-podman/issues/72 Maybe you can integrate that change into the Debian package? Best, -rt
Podman 3.0 and Debian bullseye
Dear release-team, I'm proposing to have podman 3.0 in debian/bullseye. As maintainer of the package, I'm convinced this is a good step for Debian because: - podman 3.0 will be included in RHEL 8.4, which will be released in May 2021. I expect security support for podman in Debian to become significantly simpler than let's say podman 2.2 - users have expressed interest in podman 2.2 or late (cf. #978650 and others) - podman 3.0 implements enough of docker's REST API to support docker-compose (cf. https://www.redhat.com/sysadmin/podman-docker-compose) - the salsa team has expressed interest in exploring podman to facilitate gitlab maintenance. I'd expect this update to make their lives significantly easier if included in the next stable release Current concerns/risk: - Podman 3.0.0~rc1 was only just released, but I expect it to be released soon. After all, RHEL 8.4 is scheduled for May 2021 - Podman 3 drops the legacy varlink interface. To the best of my knowledge, there are no packages in debian/testing that would require varlink (please correct me if I'm wrong here). Not having to support varlink in Debian seems a support benefit, there is little to no love for it upstream. - I've just uploaded podman 3.0 to debian/experimental, and is ready for wider testing. Uploading to unstable requires a couple of additional package updates in sid: - golang-github-containers-storage - golang-github-containers-image - golang-github-containers-common - golang-github-containers-buildah I'm not really sure if this update required formal approval by the release team, but I'd really appreciate your input in any case. Best, -rt
Re: New consul package not migrating to testing because of patroni autopkgtest?
On Wed, Dec 9, 2020 at 2:32 PM Paul Gevers wrote: > > These kind of build failures should be fixed. Builds that regularly fail > are not OK. Same goes for autopkgtest. Flaky tests are RC. > Agreed. > > What's involved with retrying autopkgtests on arm64? -- CC'ing > > debian-release@, maybe they have some input? > > Tests scheduled by the migration software (britney) to influence > migration are automatically retried every day if they fail. You could > also hit the ♻ link in the pts or qa page to retry earlier. > I must have missed that link, thanks for pointing it out! I've just tried it out for this package and got the message that the job was queued successfully. Let's see what happens. -- regards, Reinhard
Re: New consul package not migrating to testing because of patroni autopkgtest?
Turns out that the test errors were transient and someone scheduled retries for amd64 which passed. It seems we still have errors on arm64 and I expect that to go away with some retries as well. I noticed that the arm64 build also required 2 give-backs (that I scheduled using the web-ui) to build successfully. That's why I'm optimistic about retrying the autopkg tests for consul. What's involved with retrying autopkgtests on arm64? -- CC'ing debian-release@, maybe they have some input? Best, -rt On Mon, Dec 7, 2020 at 6:43 AM Reinhard Tartler wrote: > Ok, thanks! > > I have to admit that my main motivation in getting consul fixes is keeping > docker.io and podman in testing. I was under the wrong impression that > nomad was already out of testing because #973166 hit me in various > rebuilds. My bad, happy to upload nomad as well on your behalf. > > Adrian, Michael, any chance you could advise on what's going on in > https://ci.debian.net/data/autopkgtest/testing/amd64/p/patroni/8668662/log.gz > and how to resolve this? > > Best, > -rt > > On Mon, Dec 7, 2020 at 12:17 AM El boulangero > wrote: > >> Hello Reinhard! >> >> I have no idea what patroni is, so I can't really help. >> >> BTW, this upload of consul also broke the nomad build (which was broken >> anyway), but it was easy to fix, and so there should be soon a new version >> of nomad ready in Debian. >> >> In the consul package there is this note in `debian/README.source`: >> >> > Consul must stay in sync with Nomad as the latter may not build with >> newer >> > releases than what upstream vendores with Nomad. >> >> So even though I could fix the nomad build, I have no idea of how nomad >> and consul relate to each other, and I can't say if more things are broken, >> or if everything is alright. Hopefully everything is alright :) >> >> Good luck with the patroni thing, >> >> Arnaud >> >> >> On Mon, Dec 7, 2020 at 5:21 AM Reinhard Tartler >> wrote: >> >>> Hi Arnaud, hi consul and patroni package maintainers, >>> >>> I took the liberty of uploading your package update to consul in order >>> to get #975584 fixed (in the hope it doesn't lead to removal of >>> docker.io and podman and friends). Unfortunately, it seems that it >>> breaks autopkgtests in the patroni package here: >>> >>> >>> https://ci.debian.net/data/autopkgtest/testing/amd64/p/patroni/8668662/log.gz >>> >>> The thing is, I honestly don't get what in consul would break patroni. >>> Is it possible that the autopkgtest broke for reasons unrelated to consul? >>> -- I'm not familiar with python behave tests, and may that makes the log >>> very hard for me to decipher. >>> >>> What do you think is the best way to proceed from here? >>> >>> -- >>> regards, >>> Reinhard >>> >> > > -- > regards, > Reinhard > -- regards, Reinhard
Re: Update for buster slirp4netns CVE-2019-9824
Copying the debian-release mailing list, hope that's OK with everyone. On 8/24/19 6:05 AM, Moritz Mühlenhoff wrote: > On Sun, Aug 11, 2019 at 09:10:52PM +0200, Salvatore Bonaccorso wrote: >> Hi Reinhard, >> >> Apologies it took that long to come back to you in the first place. >> >> On Wed, Aug 07, 2019 at 06:13:08PM -0400, Reinhard Tartler wrote: >>> Hi Security Team, >>> >>> I have not received an answer to my question below. Any chance you >>> could get back to me on that? >> >> Unless I severely missunderstand something, slirp4netns is useful for >> instance for networking with unprivileged containers and it needs user >> namespaces to be enabled. >> >> By default those are for good reasons disabled in Debian, as well in >> buster. >> >> As such I would have said it would be enough to fix this issue for the >> upcoming point release on 7th september (so there is stil enough time >> to preare updates). >> >> Can we route you towards the point release for it? It would though be >> good to as well include as well the fix for the new CVE-2019-14378 >> (#933742) as well. Prerequisites though that it gets accepted for >> stable is that the fix is as well first in unstable. > > Agreed, enabling unprivileged user namespaces is not fully supported > by security support and Debian explicitly disables them by default > as it causes a ton of security issues in the Linux kernel (which > are often still fixed, but e.g. no DSAs are being released for such > issues). > > As such, can you fix slirp4netns by the 10.1 buster point release? > Done, I've just uploaded 0.2.3 to buster, fixing two CVEs: Changes: slirp4netns (0.2.3-1) buster; urgency=medium . * New upstream releases: - 0.2.2: check sscanf result when emulating ident, CVE-2019-9824 - 0.2.3: Fixes heap overflow in included libslirp, Closes: #933742, CVE-2019-14378 Checksums-Sha1: 459c12f439d0f2ba629d1ad5791ca49041931709 2087 slirp4netns_0.2.3-1.dsc befcd9e2f1b1fbf8b51ccac4b83536e22af12003 136459 slirp4netns_0.2.3.orig.tar.gz 370b1cf92bf21491038fc08f9d4fa3fcba432878 3968 slirp4netns_0.2.3-1.debian.tar.xz Best, -rt
Bug#929855: unblock: libheif/1.3.2-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package libheif to address CVE-2019-11471, aka #928210 in
Debian/buster.
unblock libheif/1.3.2-2
debdiff follows:
diff --git a/debian/changelog b/debian/changelog
index 9452979..23246df 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+libheif (1.3.2-2) unstable; urgency=medium
+
+ * Team Upload
+
+ [ Dylan Aïssi ]
+ * Add patch to fix CVE-2019-11471, Closes: #928210
+
+ -- Reinhard Tartler Sat, 01 Jun 2019 17:56:05 -0400
+
libheif (1.3.2-1) unstable; urgency=medium
* Imported Upstream version 1.3.2
diff --git a/debian/patches/CVE-2019-11471.patch
b/debian/patches/CVE-2019-11471.patch
new file mode 100644
index 000..767bb45
--- /dev/null
+++ b/debian/patches/CVE-2019-11471.patch
@@ -0,0 +1,60 @@
+Author: Joachim Bauch
+Description: Fix CVE-2019-11471
+ Detect and handle recursive image references.
+ Detect non-existing referenced alpha images.
+ Detect non-existing referenced depth images.
+Origin: upstream,
https://github.com/strukturag/libheif/commit/e89fbbe0705a4b8e755f148fd4c4c84007295d16
+
https://github.com/strukturag/libheif/commit/995a4283d8ed2d0d2c1ceb1a577b993df2f0e014
+
https://github.com/strukturag/libheif/commit/5a9b7f7564e158c6339f6d78a77de23720b15afd
+Bug: https://github.com/strukturag/libheif/issues/123
+ https://github.com/strukturag/libheif/issues/125
+Bug-Debian: https://bugs.debian.org/928210
+
+--- a/libheif/heif_context.cc
b/libheif/heif_context.cc
+@@ -520,6 +520,11 @@
+"Thumbnail references another thumbnail");
+ }
+
++if (image.get() == master_iter->second.get()) {
++ return Error(heif_error_Invalid_input,
++ heif_suberror_Nonexisting_item_referenced,
++ "Recursive thumbnail image detected");
++}
+ master_iter->second->add_thumbnail(image);
+
+ remove_top_level_image(image);
+@@ -566,6 +571,16 @@
+ image->set_is_alpha_channel_of(refs[0]);
+
+ auto master_iter = m_all_images.find(refs[0]);
++if (master_iter == m_all_images.end()) {
++ return Error(heif_error_Invalid_input,
++ heif_suberror_Nonexisting_item_referenced,
++ "Non-existing alpha image referenced");
++}
++if (image.get() == master_iter->second.get()) {
++ return Error(heif_error_Invalid_input,
++ heif_suberror_Nonexisting_item_referenced,
++ "Recursive alpha image detected");
++}
+ master_iter->second->set_alpha_channel(image);
+ }
+
+@@ -576,6 +591,16 @@
+ image->set_is_depth_channel_of(refs[0]);
+
+ auto master_iter = m_all_images.find(refs[0]);
++if (master_iter == m_all_images.end()) {
++ return Error(heif_error_Invalid_input,
++ heif_suberror_Nonexisting_item_referenced,
++ "Non-existing depth image referenced");
++}
++if (image.get() == master_iter->second.get()) {
++ return Error(heif_error_Invalid_input,
++ heif_suberror_Nonexisting_item_referenced,
++ "Recursive depth image detected");
++}
+ master_iter->second->set_depth_channel(image);
+
+ auto subtypes = auxC_property->get_subtypes();
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..acd8abf
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+CVE-2019-11471.patch
-- System Information:
Debian Release: 10.0
APT prefers testing
APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#927042: unblock: gpac/gpac 0.5.2-426-gc5ad4e4+dfsg5-5
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package gpac
Moritz has kindly pointed out and backported the relevant patches from upstream
that fixes this issue. Here is the relevant part of debian/changelog:
* Bug fix: "CVE-2019-11222: Buffer-overflow in gf_bin128_parse", thanks
to Salvatore Bonaccorso (Closes: #926961).
* Bug fix: "CVE-2019-11221: buffer-overflow issue in gf_import_message()
in media_import.c", thanks to Salvatore Bonaccorso (Closes: #926963).
unblock gpac/gpac 0.5.2-426-gc5ad4e4+dfsg5-5
Thanks for considering.
-rt
diff -Nru gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/changelog
gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/changelog
--- gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/changelog 2019-04-01
17:07:02.0 -0400
+++ gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/changelog 2019-04-13
16:41:15.0 -0400
@@ -1,3 +1,13 @@
+gpac (0.5.2-426-gc5ad4e4+dfsg5-5) unstable; urgency=medium
+
+ [ Moritz Muehlenhoff ]
+ * Bug fix: "CVE-2019-11222: Buffer-overflow in gf_bin128_parse", thanks
+to Salvatore Bonaccorso (Closes: #926961).
+ * Bug fix: "CVE-2019-11221: buffer-overflow issue in gf_import_message()
+in media_import.c", thanks to Salvatore Bonaccorso (Closes: #926963).
+
+ -- Reinhard Tartler Sat, 13 Apr 2019 16:41:15 -0400
+
gpac (0.5.2-426-gc5ad4e4+dfsg5-4.1) unstable; urgency=medium
* CVE-2018-7752 (Closes: #892526)
diff -Nru gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2019-11221.patch
gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2019-11221.patch
--- gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2019-11221.patch
1969-12-31 19:00:00.0 -0500
+++ gpac-0.5.2-426-gc5ad4e4+dfsg5/debian/patches/CVE-2019-11221.patch
2019-04-13 16:41:15.0 -0400
@@ -0,0 +1,180 @@
+From f4616202e5578e65746cf7e7ceeba63bee1b094b Mon Sep 17 00:00:00 2001
+From: Aurelien David
+Date: Thu, 11 Apr 2019 14:18:58 +0200
+Subject: [PATCH] fix a bunch of vsprintf -> vsnprintf
+
+closes #1203
+---
+ applications/mp4client/main.c | 2 +-
+ applications/osmo4_sym/osmo4_view.cpp | 2 +-
+ src/media_tools/media_export.c| 2 +-
+ src/media_tools/media_import.c| 2 +-
+ src/scene_manager/loader_bt.c | 4 ++--
+ src/scene_manager/loader_isom.c | 2 +-
+ src/scene_manager/loader_qt.c | 2 +-
+ src/scene_manager/loader_svg.c| 8
+ src/scene_manager/loader_xmt.c| 14 +++---
+ src/scene_manager/swf_parse.c | 6 +++---
+ src/scene_manager/swf_svg.c | 2 +-
+ src/scenegraph/xbl_process.c | 2 +-
+ src/utils/alloc.c | 2 +-
+ src/utils/xml_parser.c| 24 +---
+ 15 files changed, 49 insertions(+), 47 deletions(-)
+
+--- a/applications/mp4client/main.c
b/applications/mp4client/main.c
+@@ -1023,7 +1023,7 @@ static void on_gpac_log(void *cbk, u32 l
+
+ if (rti_logs && (lm & GF_LOG_RTI)) {
+ char szMsg[2048];
+- vsprintf(szMsg, fmt, list);
++ vsnprintf(szMsg, 2048, fmt, list);
+ UpdateRTInfo(szMsg + 6 /*"[RTI] "*/);
+ } else {
+ if (log_time_start) {
+--- a/src/media_tools/media_export.c
b/src/media_tools/media_export.c
+@@ -57,7 +57,7 @@ static GF_Err gf_export_message(GF_Media
+ va_list args;
+ char szMsg[1024];
+ va_start(args, format);
+- vsprintf(szMsg, format, args);
++ vsnprintf(szMsg, 1024, format, args);
+ va_end(args);
+ GF_LOG((u32) (e ? GF_LOG_ERROR : GF_LOG_WARNING),
GF_LOG_AUTHOR, ("%s\n", szMsg) );
+ }
+--- a/src/media_tools/media_import.c
b/src/media_tools/media_import.c
+@@ -50,7 +50,7 @@ GF_Err gf_import_message(GF_MediaImporte
+ va_list args;
+ char szMsg[1024];
+ va_start(args, format);
+- vsprintf(szMsg, format, args);
++ vsnprintf(szMsg, 1024, format, args);
+ va_end(args);
+ GF_LOG((u32) (e ? GF_LOG_WARNING : GF_LOG_INFO), GF_LOG_AUTHOR,
("%s\n", szMsg) );
+ }
+--- a/src/scene_manager/loader_bt.c
b/src/scene_manager/loader_bt.c
+@@ -121,7 +121,7 @@ static GF_Err gf_bt_report(GF_BTParser *
+ char szMsg[2048];
+ va_list args;
+ va_start(args, format);
+- vsprintf(szMsg, format, args);
++ vsnprintf(szMsg, 2048, format, args);
+ va_end(args);
+ GF_LOG((u32) (e ? GF_LOG_ERROR : GF_LOG_WARNING),
GF_LOG_PARSER, ("[BT/WRL Parsing] %s (line %d)\n", szMsg, parser->line));
+ }
+--- a/src/scene_manager/loader_isom.c
b/src/scene_manager/loader_isom.c
+@@ -144,7 +144,7 @@ static void mp4_report(GF_SceneLoader *l
+
Bug#926704: unblock: pcsc-cyberjack/3.99.5final.sp09-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package pcsc-cyberjack
As explained in
http://lists.debian.org/4e3fbda7-abe1-b106-b191-67a49c47d...@tauware.de, Frank
and I would love to see #926103 fixed for Debian 9. Please unblock this new
package that I just uploaded to unstable.
unblock pcsc-cyberjack/3.99.5final.sp09-2
For your reviewing convenience, I've included the full debdiff at the end of
this email.
Thank you in advance!
-rt
diff -Nru pcsc-cyberjack-3.99.5final.sp09/debian/changelog
pcsc-cyberjack-3.99.5final.sp09/debian/changelog
--- pcsc-cyberjack-3.99.5final.sp09/debian/changelog2017-05-29
14:33:13.0 -0400
+++ pcsc-cyberjack-3.99.5final.sp09/debian/changelog2019-04-08
17:58:31.0 -0400
@@ -1,3 +1,11 @@
+pcsc-cyberjack (3.99.5final.sp09-2) unstable; urgency=medium
+
+ * Acknowledge NMU.
+ * Bug fix: "driver breaks with pcsc-lite versions >= 1.8.21", thanks
+to Peter Wienemann (Closes: #926103).
+
+ -- Reinhard Tartler Mon, 08 Apr 2019 17:58:31 -0400
+
pcsc-cyberjack (3.99.5final.sp09-1.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru pcsc-cyberjack-3.99.5final.sp09/debian/patches/series
pcsc-cyberjack-3.99.5final.sp09/debian/patches/series
--- pcsc-cyberjack-3.99.5final.sp09/debian/patches/series 2017-05-29
14:33:11.0 -0400
+++ pcsc-cyberjack-3.99.5final.sp09/debian/patches/series 2019-04-08
17:58:31.0 -0400
@@ -1 +1,2 @@
enable_pinpad_ecom.patch
+work-with-newer-pcsc-lite.patch
diff -Nru
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch
---
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch
1969-12-31 19:00:00.0 -0500
+++
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch
2019-04-08 17:58:31.0 -0400
@@ -0,0 +1,58 @@
+commit 8ab61acfa0a8efc3c65098d4c621d761b7e05da1
+Author: Frank Neuber
+Date: Fri Apr 27 11:09:24 2018 +0200
+
+correct the large buffer problem with newer versions of pcscd
+
+--- a/cjeca32/EC30Reader.cpp
b/cjeca32/EC30Reader.cpp
+@@ -162,21 +162,23 @@ CJ_RESULT CEC30Reader::CtApplicationData
+ {
+int Res;
+ uint32_t Len;
+- uint16_t wLenRsp=0;
+- uint16_t wLenErr=0;
++ uint32_t wLenRsp=0;
++ uint32_t wLenErr=0;
+ if(ResponseLen!=0)
+- wLenRsp=(uint16_t)*ResponseLen;
++ wLenRsp=*ResponseLen;
+ if(ApplicationErrorLength!=NULL)
+- wLenErr=(uint16_t)*ApplicationErrorLength;
+- if(m_nApplicationResponseLength<(uint32_t)wLenRsp+wLenErr+4)
++ wLenErr=*ApplicationErrorLength;
++ Len=4+wLenRsp+wLenErr;
++ if(m_nApplicationResponseLength0xFFFB) // overflow or bigger than 0x - 4
++ return CJ_ERR_WRONG_PARAMETER;
+
+
if((Res=Escape(ApplicationID,Function,InputData,InputLen,Result,m_pApplicationResponse,,Slot)))
+ {
+@@ -186,10 +188,14 @@ CJ_RESULT CEC30Reader::CtApplicationData
+ *ApplicationErrorLength=0;
+ return Res;
+ }
+- memcpy(,m_pApplicationResponse,sizeof(wLenRsp));
+- wLenRsp=ReaderToHostShort(wLenRsp);
+- memcpy(,m_pApplicationResponse+2,sizeof(wLenErr));
+- wLenErr=ReaderToHostShort(wLenErr);
++
++ uint16_t wLenRsp16 = 0;
++ uint16_t wLenErr16 = 0;
++ memcpy(,m_pApplicationResponse,sizeof(wLenRsp16));
++ wLenRsp=ReaderToHostShort(wLenRsp16);
++ memcpy(,m_pApplicationResponse+2,sizeof(wLenErr16));
++ wLenErr=ReaderToHostShort(wLenErr16);
++
+ if(ApplicationErrorLength)
+ {
+ if(wLenErr>*ApplicationErrorLength)
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing'), (50, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Freeze-exception for pcsc-cyberjack 3.99.5final.sp09-2
Hi Release Team,
Frank and I would like to see RC bug #926103 fixed in Debian 10. Please approve
the attached debdiff, so that I can upload the fixed package to unstable.
Thank you for your consideration.
Best,
Reinhard
diff -Nru pcsc-cyberjack-3.99.5final.sp09/debian/changelog
pcsc-cyberjack-3.99.5final.sp09/debian/changelog
--- pcsc-cyberjack-3.99.5final.sp09/debian/changelog2017-05-29
14:33:13.0 -0400
+++ pcsc-cyberjack-3.99.5final.sp09/debian/changelog2019-04-08
17:58:31.0 -0400
@@ -1,3 +1,11 @@
+pcsc-cyberjack (3.99.5final.sp09-2) unstable; urgency=medium
+
+ * Acknoledge NMU.
+ * Bug fix: "driver breaks with pcsc-lite versions >= 1.8.21", thanks
+to Peter Wienemann (Closes: #926103).
+
+ -- Reinhard Tartler Mon, 08 Apr 2019 17:58:31 -0400
+
pcsc-cyberjack (3.99.5final.sp09-1.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru pcsc-cyberjack-3.99.5final.sp09/debian/patches/series
pcsc-cyberjack-3.99.5final.sp09/debian/patches/series
--- pcsc-cyberjack-3.99.5final.sp09/debian/patches/series 2017-05-29
14:33:11.0 -0400
+++ pcsc-cyberjack-3.99.5final.sp09/debian/patches/series 2019-04-08
17:58:31.0 -0400
@@ -1 +1,2 @@
enable_pinpad_ecom.patch
+work-with-newer-pcsc-lite.patch
diff -Nru
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch
---
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch
1969-12-31 19:00:00.0 -0500
+++
pcsc-cyberjack-3.99.5final.sp09/debian/patches/work-with-newer-pcsc-lite.patch
2019-04-08 17:58:31.0 -0400
@@ -0,0 +1,58 @@
+commit 8ab61acfa0a8efc3c65098d4c621d761b7e05da1
+Author: Frank Neuber
+Date: Fri Apr 27 11:09:24 2018 +0200
+
+correct the large buffer problem with newer versions of pcscd
+
+--- a/cjeca32/EC30Reader.cpp
b/cjeca32/EC30Reader.cpp
+@@ -162,21 +162,23 @@ CJ_RESULT CEC30Reader::CtApplicationData
+ {
+int Res;
+ uint32_t Len;
+- uint16_t wLenRsp=0;
+- uint16_t wLenErr=0;
++ uint32_t wLenRsp=0;
++ uint32_t wLenErr=0;
+ if(ResponseLen!=0)
+- wLenRsp=(uint16_t)*ResponseLen;
++ wLenRsp=*ResponseLen;
+ if(ApplicationErrorLength!=NULL)
+- wLenErr=(uint16_t)*ApplicationErrorLength;
+- if(m_nApplicationResponseLength<(uint32_t)wLenRsp+wLenErr+4)
++ wLenErr=*ApplicationErrorLength;
++ Len=4+wLenRsp+wLenErr;
++ if(m_nApplicationResponseLength0xFFFB) // overflow or bigger than 0x - 4
++ return CJ_ERR_WRONG_PARAMETER;
+
+
if((Res=Escape(ApplicationID,Function,InputData,InputLen,Result,m_pApplicationResponse,,Slot)))
+ {
+@@ -186,10 +188,14 @@ CJ_RESULT CEC30Reader::CtApplicationData
+ *ApplicationErrorLength=0;
+ return Res;
+ }
+- memcpy(,m_pApplicationResponse,sizeof(wLenRsp));
+- wLenRsp=ReaderToHostShort(wLenRsp);
+- memcpy(,m_pApplicationResponse+2,sizeof(wLenErr));
+- wLenErr=ReaderToHostShort(wLenErr);
++
++ uint16_t wLenRsp16 = 0;
++ uint16_t wLenErr16 = 0;
++ memcpy(,m_pApplicationResponse,sizeof(wLenRsp16));
++ wLenRsp=ReaderToHostShort(wLenRsp16);
++ memcpy(,m_pApplicationResponse+2,sizeof(wLenErr16));
++ wLenErr=ReaderToHostShort(wLenErr16);
++
+ if(ApplicationErrorLength)
+ {
+ if(wLenErr>*ApplicationErrorLength)
Re: gpac_0.7.1+dfsg1-1_amd64.changes is NEW
On 4/4/19 3:38 PM, Moritz Mühlenhoff wrote: > On Tue, Apr 02, 2019 at 10:40:44PM -0400, Reinhard Tartler wrote: >> Ah, that's great news. I didn't realize that Moritz backported the >> security fixes to an earlier upstream version. I managed to locate the >> git commits but wasn't comfortable with backporting them to version 0.5.2, >> not all of them applied cleanly and I lacked the confidence to resolve >> the conflicts. >> >> Thanks Moritz for taking care of this! > > Yeah, I sent a mail to debian-multimedia@ldo about this, but seems to have > fallen through the cracks: > https://lists.debian.org/debian-multimedia/2019/03/msg00081.html That's entirely possible, I must have overlooked that email. My apologies. > BTW, I also prepared an MR on salsa for the remaining open security issues > in src:audiofile, it would be great if anyone in the debian multimedia > team could merge and upload: > https://salsa.debian.org/multimedia-team/audiofile/merge_requests/1 Seems Sebastian already took care of this and the upload last Friday. :-) >> Given we do have those RC bugs fixed with more targeted patches, I >> no longer see the urgency to get 0.7.1 into unstable. Would you agree >> with having 0.7.1 in experimental instead? If so, I'd upload it as >> 0.7.1-2 to experimental. > > experimental should be fine, as it's totally to the freeze process. Uploaded 0.7.1-2 to experimental, which is (again) in NEW. Thorsten, let me know if there are any issues with that upload. Cheers, -rt signature.asc Description: OpenPGP digital signature
Re: gpac_0.7.1+dfsg1-1_amd64.changes is NEW
On 4/2/19 3:08 PM, Niels Thykier wrote: > Thorsten Alteholz: >> Hi Reinhard, >> >> On Tue, 2 Apr 2019, Reinhard Tartler wrote: >>> Now about 6 weeks have passed since I've been uploading this package, and >>> I do have a question: Is there anything wrong with this package? >> >> yes, you did an upload to unstable. At this time of the freeze and >> without a notice from the maintainer/release team this is usually wrong. I did the upload on 2/15. At the time of the upload, I missed the deadline for the soft freeze by three days. I don't consider this a large or disruptive change so I uploaded the package hoping it to get accepted anyways. Admittedly, I then lost track of this package and realized only earlier today that it still hadn't made it to unstable. My bad, sorry! >>> I'm CC'ing the release team to inform them about this upload. >> >> Ok, so is this version suitable for buster? >> >> Thorsten >> > > Note that gpac/0.5.2-426-gc5ad4e4+dfsg5-4.1 is currently in sid, > recorded as fixing #892526, #902782 and #921969. Therefore, please hold > gpac/0.7.1+dfsg1-1 in NEW for now until the sid version can migrate to > testing. Ah, that's great news. I didn't realize that Moritz backported the security fixes to an earlier upstream version. I managed to locate the git commits but wasn't comfortable with backporting them to version 0.5.2, not all of them applied cleanly and I lacked the confidence to resolve the conflicts. Thanks Moritz for taking care of this! > > As for gpac/0.7.1+dfsg1-1, I cannot find a debdiff for it on the mailing > list nor the BTS. Therefore, I have no clue whether it is suitable for > buster. The debdiff is unreasonably large (several MiB), there are a *lot* of unrelated upstream changes included. I'll spare you to review it. Given we do have those RC bugs fixed with more targeted patches, I no longer see the urgency to get 0.7.1 into unstable. Would you agree with having 0.7.1 in experimental instead? If so, I'd upload it as 0.7.1-2 to experimental. Let me know if you have any thoughts or concerns on that. Best, -rt
Re: gpac_0.7.1+dfsg1-1_amd64.changes is NEW
Dear ftp-master team, On 2/15/19 7:20 AM, Debian FTP Masters wrote: > binary:libgpac7 is NEW. > binary:libgpac7 is NEW. > > Your package has been put into the NEW queue, which requires manual action > from the ftpteam to process. The upload was otherwise valid (it had a good > OpenPGP signature and file hashes are valid), so please be patient. > > Packages are routinely processed through to the archive, and do feel > free to browse the NEW queue[1]. > > If there is an issue with the upload, you will receive an email from a > member of the ftpteam. > > If you have any questions, you may reply to this email. Now about 6 weeks have passed since I've been uploading this package, and I do have a question: Is there anything wrong with this package? As you can see from https://ftp-master.debian.org/new/gpac_0.7.1+dfsg1-1.html, it fixes RC bugs, and I would recommend to include it in the next stable release, buster. Please let me know if you have any questions and concerns about this upload. I'm CC'ing the release team to inform them about this upload. It will require a binNMU of the only dependent package, x264. I've test-built it locally and don't expect any issues with that. Thank you for your consideration. Best, Reinhard
Bug#859216: unblock: jackd2/1.9.10+20150825git1ed50c92~dfsg-5
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package jackd2
It fixes RC bug #858525.
diff --git a/debian/changelog b/debian/changelog
index 7bd384a..93111e6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+jackd2 (1.9.10+20150825git1ed50c92~dfsg-5) unstable; urgency=medium
+
+ * Move libjackserver into package libjack-jackd2-0. This avoids a
+dangling symbolic link in the package libjack-jackd2-dev.
+(Closes: #858525)
+
+ -- Reinhard Tartler <siret...@tauware.de> Mon, 27 Mar 2017 22:44:11 -0400
+
jackd2 (1.9.10+20150825git1ed50c92~dfsg-4) unstable; urgency=medium
* Team upload.
diff --git a/debian/control b/debian/control
index 51dad7d..5547eed 100644
--- a/debian/control
+++ b/debian/control
@@ -62,7 +62,7 @@ Conflicts: jackd2 (>> ${binary:Version}),
libjack-0.125
Suggests: jackd2 (= ${binary:Version})
Provides: libjack-0.116, libjack-0.125
-Replaces: libjack-0.116, libjack-0.125
+Replaces: libjack-0.116, libjack-0.125, jackd2 (<<
1.9.10+20150825git1ed50c92~dfsg-5)
Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends}
Description: JACK Audio Connection Kit (libraries)
diff --git a/debian/jackd2.install b/debian/jackd2.install
index 9c48e99..44c00ce 100644
--- a/debian/jackd2.install
+++ b/debian/jackd2.install
@@ -1,5 +1,4 @@
usr/bin/jack*
-usr/lib/*/libjackserver.so.*
usr/lib/*/jack/netmanager.so
usr/lib/*/jack/profiler.so
usr/lib/*/jack/inprocess.so
diff --git a/debian/libjack-jackd2-0.install b/debian/libjack-jackd2-0.install
index 3d9c622..cc5e6b4 100644
--- a/debian/libjack-jackd2-0.install
+++ b/debian/libjack-jackd2-0.install
@@ -1,2 +1,3 @@
usr/lib/*/libjack.so.*
usr/lib/*/libjacknet.so.*
+usr/lib/*/libjackserver.so.*
diff --git a/debian/shlibs.local b/debian/shlibs.local
new file mode 100644
index 000..cffbce7
--- /dev/null
+++ b/debian/shlibs.local
@@ -0,0 +1,3 @@
+libjack 0 libjack-jackd2-0 (>= 1.9.10+20150825) | libjack-0.125
+libjacknet 0 libjack-jackd2-0 (>= 1.9.5~dfsg-14)
+libjackserver 0 libjack-jackd2-0 (>= 1.9.10+20150825git1ed50c92~dfsg-5)
unblock jackd2/1.9.10+20150825git1ed50c92~dfsg-5
Re: boxbackup 0.11.1~r2837-2 migration issue
Great, thanks! I remember that build failure. It was because of a bug in the latex packages (missing dependencies IIRC). I'm confident that just trying the build again would result in a functional build. Can you please trigger a rebuild (i.e., give it back to the queue)? Thanks. On Sun, Jun 12, 2016 at 11:55 AM Adam D. Barratt <a...@adam-barratt.org.uk> wrote: > On Sun, 2016-06-12 at 15:41 +, Reinhard Tartler wrote: > > > I wonder why boxbackup did not migrate to testing. According to > > https://release.debian.org/migration/testing.pl?package=boxbackup the > > issue is a missing armhf build. > > Correct. > > > However, > > > https://buildd.debian.org/status/logs.php?arch=armhf=boxbackup=0.11.1~r2837-1 > indicates it built just fine. > > You're using the logs for one version to suggest that a different > version should be able to migrate. > > Your first link refers to 0.11.1~r2837-2, which indeed doesn't have an > armhf build. See > > https://buildd.debian.org/status/logs.php?arch=armhf=boxbackup=0.11.1~r2837-2 > > Regards, > > Adam > > >
boxbackup 0.11.1~r2837-2 migration issue
Hi, I wonder why boxbackup did not migrate to testing. According to https://release.debian.org/migration/testing.pl?package=boxbackup the issue is a missing armhf build. However, https://buildd.debian.org/status/logs.php?arch=armhf=boxbackup=0.11.1~r2837-1 indicates it built just fine. What's the issue? -rt
Bug#807280: jessie-pu: package keepassx/0.4.3+dfsg-0.1
On December 7, 2015 4:37:03 PM EST, "Adam D. Barratt" <a...@adam-barratt.org.uk> wrote: >Control: tags -1 + pending > >On Sun, 2015-12-06 at 19:33 -0500, Reinhard Tartler wrote: >> I'm writing you to request approving my recent upload of >> keepassx_0.4.3+dfsg-0.1+deb8u1. This update addresses >> CVE-2015-8378/#791858. I'm copying Moritz, since he asked me to >prepare >> an upload to stable (I've already uploaded keepassx_0.4.3+dfsg-1, >which >> also has a fix for this included, to unstable). > >We generally prefer that things happen the other way around - the >discussion, then the upload. Noted, will do so in future. >In any case, flagged for acceptance, thanks. Thanks for still accepting the package! Reinhard -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#807280: jessie-pu: package keepassx/0.4.3+dfsg-0.1
Package: release.debian.org Severity: normal Tags: jessie User: release.debian@packages.debian.org Usertags: pu Dear Release Team, I'm writing you to request approving my recent upload of keepassx_0.4.3+dfsg-0.1+deb8u1. This update addresses CVE-2015-8378/#791858. I'm copying Moritz, since he asked me to prepare an upload to stable (I've already uploaded keepassx_0.4.3+dfsg-1, which also has a fix for this included, to unstable). Thanks, Reinhard -- System Information: Debian Release: jessie/sid APT prefers vivid-updates APT policy: (500, 'vivid-updates'), (500, 'vivid-security'), (500, 'vivid') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.19.0-33-generic (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Re: Bug#771126: libav/tests/lena.pnm: also not mentioned in debian/copyright
On Fri, Nov 28, 2014 at 1:34 AM, Niels Thykier ni...@thykier.net wrote: Control: tags -1 -wheezy-ignore On 2014-11-27 23:23, Jonas Smedegaard wrote: Quoting Niels Thykier (2014-11-27 22:14:25) [...] In prior similar bugreport https://bugs.debian.org/760171#10 - referenced from https://bugs.debian.org/771191#10 - distribution is documented as permitted only for research and education which I interpret as unacceptable for Debian. [...] - Jonas FTR, this whole business feel incredibly silly. lena.pnm has become the *de-facto* standard image for every CS student to do his graphics courses homework on, and is generally considered to public domain, even without proper documentation. The copyright holder is going to have a very hard time enforcing his right if he wanted to prevent distribution of the image, in particular the low-quality scan that is being used in the Libav source package. Also, even according to https://en.wikipedia.org/wiki/File:Lenna.png#Licensing, the holder is not interested in that to begin with. - I mean, really, don't we have more important things to do? Nevertheless, lena.pnm lacks proper licensing and some argue it violates the DFSG, so I've taken the effort (and ridicule!) to replace lena.pnm upstream with a new image reference.pnm, which I have personally taken this summer and upon Jonas' suggestion provide it under the expat license. This required to update all test reference patterns, which took most of the effort and is basically not verifiable. Jonas, would you mind taking over from here and upload https://libav.org/releases/libav-11.1.tar.xz to unstable? Otherwise I can see if I can get to that this weekend. Regarding stable: I've backported this change back to release/0.8 upstream. In the past, the security team has accepted libav point releases in wheezy-security, and I trust that this is also an acceptable change. It will be part of the next upload to stable-security. (this may take some more weeks, as libav has been notified about a couple of more CVEs, which need to be tested, fixed and verified, which is incredibly laborsome to do correctly). Does this plan work for everyone? -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ0cceY8c9rp3jO+=mkp8ctjcdj7d9yxgnewhhrfm0ntbka...@mail.gmail.com
Re: FFmpeg in Jessie
On Fri, Sep 26, 2014 at 5:28 PM, Andreas Barth a...@ayous.org wrote: That sounds like we should drop libav and release with ffmpeg. Is this also the opinion of the libav maintainers? Or is there a strong reason why this is not possible? This was extensively discussed previously on debian-devel this August and September. See the thread starting at: https://lists.debian.org/debian-devel/2014/07/msg01010.html You can read on my position on that matter in: https://lists.debian.org/debian-devel/2014/08/msg00160.html https://lists.debian.org/debian-devel/2014/08/msg00269.html Long story short: I have great concerns with even having the package in its current form in experimental or unstable. I would not recommend accepting the 'ffmpeg' package currently in unstable to testing. -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caj0cceauuzm3kg3hrimt8vqr_1xrh2rn0jo7kwxnofnzam_...@mail.gmail.com
Bug#757917: transition: libav11
On Tue, Aug 26, 2014 at 6:31 PM, Reinhard Tartler siret...@gmail.com wrote: On Tue, Aug 26, 2014 at 4:29 PM, Emilio Pozuelo Monfort po...@debian.org wrote: On 26/08/14 16:05, Reinhard Tartler wrote: On Mon, Aug 18, 2014 at 4:25 PM, Emilio Pozuelo Monfort po...@debian.org wrote: On 18/08/14 21:33, Andrew Kelley wrote: On Aug 18, 2014 12:22 PM, Emilio Pozuelo Monfort po...@debian.org wrote: I want to get perl in first. Ping me again when that happens if I haven't replied. Pardon my ignorance but why can't those both happen at the same time? https://release.debian.org/transitions/html/auto-libav.html Collisions: xmms2 → perl5.20 Now with perl in testing, are we good to proceed with me uploading libav11 to unstable? I got lost with all the small partial updates. Can you give a summary of how things are standing? i.e. what can be binnmued, what FTBFS... AFAIUI, everything can be binnmu'ed right now. Also vlc needs fixing. A fixed VLC entered unstable today fixes that. As noted on irc, it turns out that vlc FTBFS on mips. I'm sure we'll be able to find a solution for that during the transition, though. A fixed glib2.0 just was just uploaded. Emilio, can you please dep-wait vlc/mips on glib2.0_2.40.0-5 (which is currently building)? Thanks! -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caj0cceazgvcaqz40o0+tvo4i2hclzvqi0z2fqitjjowr-kn...@mail.gmail.com
Bug#757917: transition: libav11
On Mon, Aug 18, 2014 at 4:25 PM, Emilio Pozuelo Monfort po...@debian.org wrote: On 18/08/14 21:33, Andrew Kelley wrote: On Aug 18, 2014 12:22 PM, Emilio Pozuelo Monfort po...@debian.org wrote: I want to get perl in first. Ping me again when that happens if I haven't replied. Pardon my ignorance but why can't those both happen at the same time? https://release.debian.org/transitions/html/auto-libav.html Collisions: xmms2 → perl5.20 Now with perl in testing, are we good to proceed with me uploading libav11 to unstable? Best, Reinhard -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ0cceZRQJ1T_SEpVMR3Zc3i4i5=rfps3xheyv_omc0rnaw...@mail.gmail.com
Bug#757917: transition: libav11
On Tue, Aug 26, 2014 at 4:29 PM, Emilio Pozuelo Monfort po...@debian.org wrote: On 26/08/14 16:05, Reinhard Tartler wrote: On Mon, Aug 18, 2014 at 4:25 PM, Emilio Pozuelo Monfort po...@debian.org wrote: On 18/08/14 21:33, Andrew Kelley wrote: On Aug 18, 2014 12:22 PM, Emilio Pozuelo Monfort po...@debian.org wrote: I want to get perl in first. Ping me again when that happens if I haven't replied. Pardon my ignorance but why can't those both happen at the same time? https://release.debian.org/transitions/html/auto-libav.html Collisions: xmms2 → perl5.20 Now with perl in testing, are we good to proceed with me uploading libav11 to unstable? I got lost with all the small partial updates. Can you give a summary of how things are standing? i.e. what can be binnmued, what FTBFS... AFAIUI, everything can be binnmu'ed right now. Also vlc needs fixing. A fixed VLC entered unstable today fixes that. As noted on irc, it turns out that vlc FTBFS on mips. I'm sure we'll be able to find a solution for that during the transition, though. -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caj0cceafmsavf1mzjr3vk_99fs1zqf2jwcpozyk9yugz0of...@mail.gmail.com
Bug#757917: transition: libav11
On Sat, Aug 16, 2014 at 11:24 AM, Reinhard Tartler siret...@gmail.com wrote: vlc FAIL (silly configure check fail, will sort out with upstream) Turns out to be sligtly more complicated as thought. After consultation with j-b (videolan upstream), we decided that we really should go with vlc 2.2 for jessie. This, however, requires new upstream releases of libdvdread and libdvdnav (j-b blogged on this: http://www.jbkempf.com/blog/post/2014/dvdread-dvdnav-and-dvdcss) I've uploaded both packages, the next step would be to update vlc to 2.2. VLC 2.2 pre2 is now uploaded to unstable. Because of a SONAME bump of libvlccore, it requires going through, but I expect that to be really trivial. Now with all packages fixed, are we good to proceed with libav11 in unstable now? -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caj0ccez3espk7ufua_11rmt9e4evjqjderc5xmu5x85jbdd...@mail.gmail.com
Bug#757917: transition: libav11
On Wed, Aug 13, 2014 at 9:07 PM, Reinhard Tartler siret...@gmail.com wrote: linphone FAIL, #758017, NMU uploaded to 5/days vlc FAIL (silly configure check fail, will sort out with upstream) Turns out to be sligtly more complicated as thought. After consultation with j-b (videolan upstream), we decided that we really should go with vlc 2.2 for jessie. This, however, requires new upstream releases of libdvdread and libdvdnav (j-b blogged on this: http://www.jbkempf.com/blog/post/2014/dvdread-dvdnav-and-dvdcss) I've uploaded both packages, the next step would be to update vlc to 2.2. -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caj0ccezddh1_5keqmuka6so3+ewhf42ngtfpcmbvvpdyniz...@mail.gmail.com
Bug#757917: transition: libav11
On Wed, Aug 13, 2014 at 9:07 PM, Reinhard Tartler siret...@gmail.com wrote: gst-libav1.0 FAIL (fixed in 11~alpha2-1) [...] gst-libav: will be fixed with a new libav package that I'm about to upload confirmed that gst-libav can now that be binNMUed against libav_11~alpha2-1 or later. -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caj0ccebp8vu+uruqoarqtfjxg_m5d58b3dqnt-w6go3jzoa...@mail.gmail.com
Bug#757917: transition: libav11
On Aug 14, 2014 8:18 AM, Emilio Pozuelo Monfort po...@debian.org wrote: On 12/08/14 13:41, Reinhard Tartler wrote: A prerelease for Libav11 that passes upstream's extensive test suite is currently in debian/experimental, and I'll make sure that the final release will be done and uploaded before jessie freeze. Hmm, so there's only an alpha for now... How stable is it? Are there going to be further ABI changes before the final release? Is there a schedule / roadmap? I'm not very confident with doing the transition until there's a beta or an RC with an ABI stability promise. Thanks for your concern. I also act as release manager and am happy to say that we'll make sure that no abi breaking change happens before the final release. There is no beta release yet because there is currently a change being discussed that may cause a shlibs bump. I don't expect this to affect this transition for jessie. In any case, we'll also try to finalize beta1 this weekend. Cheers Reinhard
Bug#757917: transition: libav11
On Wed, Aug 13, 2014 at 5:25 PM, Emilio Pozuelo Monfort po...@debian.org wrote: There already is https://release.debian.org/transitions/html/auto-libav.html Lovely! This sounds good in principle, but I would like to hear about the results of a mass-rebuild of the rdeps. OK, I've let me amd64 workstation try to build all packages in jessie listed on the URL above. Here are the results: acoustid-fingerprinter PASS alsa-plugins PASS amarok build deps uninstallable amide PASS aubio PASS audacious-plugins PASS avifile PASS bino FAIL (unrelated to libav, #757280) blender PASS (according to sramacher) cantata PASS chromaprint PASS cmus PASS dff PASS dvbcut PASS ffdiaporama PASS ffmpeg2theora PASS ffmpegthumbnailer PASS ffmpegthumbs PASS ffms2 PASS freerdp PASS fuse-emulator-utils PASS gegl PASS gimp-gap PASS gmerlin-avdecoder PASS gmerlin-encoders PASS gmic PASS gnash PASS goldendict PASS gpac PASS gst-libav1.0 FAIL (fixed in 11~alpha2-1) guvcview PASS handbrake PASS harvid PASS hedgewars PASS idjc PASS jitsi PASS jugglemaster PASS k3b PASS kdenlivePASS kfilemetadata PASS kid3 PASS kino PASS kradio4 PASS lebiniou (using -Werror ?! - easily patchable) libextractor PASS libgroove PASS libomxil-bellagio PASS libphash PASS libpostproc PASS libquicktime PASS lightspark PASS linphone PASS lives PASS lynkeos.app PASS mediatomb PASS mlt PASS moc PASS motion PASS mpd PASS mplayer2 PASS mpv PASS nepomuk-core PASS opal FAIL (unrelated to libav11, cf. #728452) opencv PASS openscenegraph PASS ovito PASS paraview PASS qmmp PASS qutecom PASS shotdetect PASS silan PASS spek PASS squeezelite PASS strigi PASS survex PASS transcode PASS tupi PASS vdr-plugin-xineliboutput PASS vice PASS visp FAIL (unrelated to libav11, cf. #756784) vlc FAIL (silly configure check fail, will sort out with upstream) vtk FAIL (unrelated to libav11, cf. #713794) vtk6 PASS wxsvg PASS x264 PASS xbmc PASS xbmc-pvr-addons PASS xine-lib-1.2 PASS xjadeo PASS xmms2 PASS xpra PASS yorick-av PASS TL;DR summary: gst-libav: will be fixed with a new libav package that I'm about to upload vlc: silly configure check needs to be fixed, I'll sort this out with j-b upstream lebiniou: Compiling with -Werror is silly, can be easily patched 4 further packages FTBFS for reasons unrealated to libav. All in all, it seems to me that upstream is right and Libav11 is source-code compatible to libav10 for practically all packages in jessie. How to proceed from here? -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caj0ccebtkoas8kyy7ns9dkrkugl9sqow6mrwmxt33a4c_xj...@mail.gmail.com
Bug#757917: transition: libav11
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, I would like to upload libav11 to unstable, which requires the recompilation of any package that links against it. A prerelease for Libav11 that passes upstream's extensive test suite is currently in debian/experimental, and I'll make sure that the final release will be done and uploaded before jessie freeze. Unlike previous transitions, this should be less painful compared to Libav10 or Libav9, because Libav11 maintains full source-code compatibility, cf. to the release announcement: https://libav.org/news.html: The API remains backward compatible, so no source changes should be required in the code that works with Libav 10. We note however, that a number of obsolete APIs remain deprecated and will be removed in the future. All users are strongly encouraged to update their code. A work in progress migration guide can be found at our wiki. If you are still having difficulty after reading the migration guide, please do not hesitate to file a report in our Bugzilla. We have a special category for porting issues. Proposed ben file: Affected: .build-depends ~ /lib(avcodec|avformat|avutil|device|filter|avresample)-dev/ Bad: .depends ~ /lib(avcodec55|avformat55|avutil53|device54|filter4|avresample1)/ Good: .depends ~ /lib(avcodec56|avformat56|avutil54|device55|filter5|avresample2)/ Moritz, do you still have the infrastructure and/or scripts that you used for the libav10 test rebuild so that we can verify that everything still builds with libav11? I can give it a shot but unlikely before this weekend. If not, maybe someone else would be willing to fill in? -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ0ccebZoVe5QX6cnfX2G8qv-sKsC9hB461En=k03qxveow...@mail.gmail.com
Bug#753822: aspectc++: please allow transition to testing
Package: release.debian.org I believe Aspectc++ is currently kept out of testing because it FTBFS on armel and armhf. Neither I nor upstream have the resources to support these architectures, and users won't use this package on arm generally anyways. Can you please give guidance on what can be done instead of fixing it on ARM to allow aspectc++ into jessie? Thanks for your assistance Reinhard -- System Information: Debian Release: 7.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.13.0-29-generic (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140705134922.16484.26347.reportbug@debian-build
Bug#739079: transition: libav10
Now that libav transitioned to testing, and https://release.debian.org/transitions/ says '100%' next to the libav transition, what's left to be done here? Best, Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ0cceZtuYPAnYmTeVhrvLagib8UyFMztaDtM8QLA=rqart...@mail.gmail.com
Bug#739079: First round of binNMU request for libav 10
On Thu, May 15, 2014 at 12:39 PM, Moritz Muehlenhoff j...@inutil.org wrote: On Tue, May 13, 2014 at 10:31:14PM +0200, Julien Cristau wrote: On Tue, May 13, 2014 at 17:37:58 +0200, Julien Cristau wrote: On Tue, May 13, 2014 at 17:00:32 +0200, Moritz Muehlenhoff wrote: nmu tupi_0.2+git04-1 . ALL . -m Rebuild against libav10. Done. Though #747832 is still going to block its migration. I followed up on the bug. I also recommend to remove renpy from testing. Porting to libav10 requires some more invasive porting upstream and renpy is a leaf package. Porting performous is in the works, but not done. I also recommend to remove it for now: https://github.com/performous/performous/issues/79 libavg is another leaf package that could be temporarily removed from testing. -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caj0ccez2s-_kaq5bvmfc9c0z8w-qom8epy5p0tfmqnpeqq6...@mail.gmail.com
Bug#739079: First round of binNMU request for libav 10
On Mon, May 12, 2014 at 5:01 AM, Julien Cristau jcris...@debian.org wrote: On Sun, May 11, 2014 at 22:02:38 -0400, Reinhard Tartler wrote: Hi, The following packages from pkg-multimedia build just fine for me: nmu lives_2.2.4~ds0-2 . ALL . -mrebuild against libav10 nmu chromaprint_1.1-1 . ALL . -mrebuild against libav10 nmu idjc_0.8.14-1 . ALL . -mrebuild against libav10 nmu silan_0.3.2-2 . ALL . -mrebuild against libav10 nmu wxsvg_2:1.3~dfsg-1 . ALL . -mrebuild against libav10 Scheduled. Note that you need a space between -m and the message. Ok nmu libffms2-3_2.19.1-1 . ALL . -mrebuild against libav10 That's not the name of a source package. Sorry, that should have read: nmu ffms2_2.19.1-1 . ALL . -m rebuild against libav10 Thanks -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ0cceaj7qU=0qv_y_hfoewhkyzt2erehdz71hgcw_ed6ev...@mail.gmail.com
Bug#739079: transition: libav10
On Sun, May 11, 2014 at 9:16 AM, Julien Cristau jcris...@debian.org wrote: On Thu, May 8, 2014 at 20:35:55 -0400, Reinhard Tartler wrote: On Tue, May 6, 2014 at 9:39 AM, Bálint Réczey bal...@balintreczey.hu wrote: When do you plan starting the transition? How about opening it with Libav 10.1? ;-) I think we are in a pretty good position for startin now. I agree. Let me upload 10.1 this weekend to unstable to finally start this transition. What's the status of the remaining 8 open bugs? (Mostly interested in vtk and opencv, since they're the ones with reverse deps, I think.) I've just uploaded NMUs for vtk and opencv to DELAYED/5, but I can reschedule them if you think that this would be appropriate. for the rest, I'd think that there is a very good chance that the respective maintainers are going to fix them before they turn out to be actual blockers of the transition. If they do, let's remove them temporarily from testing. I mean, uploading libav10 to unstable will require many additional sourceful uploads of package versions that are currently in experimental, which will take some time by itself. I'd suggest let's start with that. -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caj0cceb5rtdmm+vkfhnynutq8nlavonk5mpx20mgynt_trk...@mail.gmail.com
Bug#739079: transition: libav10
On Sun, May 11, 2014 at 11:50 AM, Julien Cristau jcris...@debian.org wrote: On Sun, May 11, 2014 at 11:25:49 -0400, Reinhard Tartler wrote: for the rest, I'd think that there is a very good chance that the respective maintainers are going to fix them before they turn out to be actual blockers of the transition. If they do, let's remove them temporarily from testing. I mean, uploading libav10 to unstable will require many additional sourceful uploads of package versions that are currently in experimental, which will take some time by itself. I'd suggest let's start with that. So the fact that it'll require sourceful uploads of lots of packages with many different maintainers is actually a big part of what makes this painful for us. The easiest transitions are the ones where a rebuild is all that's necessary, and fewer people need to be involved to upload things at more or less the same time. I see. Unfortunately, it is unrealistic to prepare all of libav's reverse dependencies in this way, which is why I need I'm asking for assistance. I'm sorry to cause this amount of pain to you, but I don't see how to do better here. Would a timeline like this work for you: - T: upload libav to unstable - T+0: upgrade all FTBFS bugs to serious severity, ask maintainers to move the updated packages from experimental to sid - T+1 day (approximately): libav is built on all archs in sid - T+1 week: libav maintainers (+ anyone else interested) start NMUing the remaining packages (without delay) - T+2 weeks (hopefully): everything is rebuilt and can move to testing ? That would be beautiful. From my side, I would appreciate it very much if we could make T==today. For reference last time took 2 months. I'll be doing my best to make it happen faster this time. -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caj0cceztny-oktk8blbebab+nv6z3eojg8xusxqgwc1ok9v...@mail.gmail.com
Bug#739079: transition: libav10
On Sun, May 11, 2014 at 12:20 PM, Julien Cristau jcris...@debian.org wrote: Control: tag -1 confirmed On Sun, May 11, 2014 at 12:05:55 -0400, Reinhard Tartler wrote: On Sun, May 11, 2014 at 11:50 AM, Julien Cristau jcris...@debian.org wrote: Would a timeline like this work for you: - T: upload libav to unstable - T+0: upgrade all FTBFS bugs to serious severity, ask maintainers to move the updated packages from experimental to sid - T+1 day (approximately): libav is built on all archs in sid - T+1 week: libav maintainers (+ anyone else interested) start NMUing the remaining packages (without delay) - T+2 weeks (hopefully): everything is rebuilt and can move to testing ? That would be beautiful. From my side, I would appreciate it very much if we could make T==today. For reference last time took 2 months. I'll be doing my best to make it happen faster this time. OK, let's go ahead then. Thanks, uploaded and ACCEPTED. -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ0ccebJc3qz=4b_wzSvNk80Ppby8bdJ_UTs5rtg97=vfVZ=h...@mail.gmail.com
Bug#739079: First round of binNMU request for libav 10
Hi, The following packages from pkg-multimedia build just fine for me: nmu lives_2.2.4~ds0-2 . ALL . -mrebuild against libav10 nmu chromaprint_1.1-1 . ALL . -mrebuild against libav10 nmu libffms2-3_2.19.1-1 . ALL . -mrebuild against libav10 nmu idjc_0.8.14-1 . ALL . -mrebuild against libav10 nmu silan_0.3.2-2 . ALL . -mrebuild against libav10 nmu wxsvg_2:1.3~dfsg-1 . ALL . -mrebuild against libav10 Please schedule binNMUs. Thanks. -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ0ccea0opGA9se1tPGJc=mxrn6rj_owhaywjhqyigopwxc...@mail.gmail.com
Bug#739079: transition: libav10
On Tue, May 6, 2014 at 9:39 AM, Bálint Réczey bal...@balintreczey.hu wrote: When do you plan starting the transition? How about opening it with Libav 10.1? ;-) I think we are in a pretty good position for startin now. I agree. Let me upload 10.1 this weekend to unstable to finally start this transition. -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caj0cceye+4tsqj5dp4xdpethmoa3gt+lgdrouojnvsv9i-w...@mail.gmail.com
Bug#738978: transition: x264
On Sat, Apr 5, 2014 at 9:31 AM, Reinhard Tartler siret...@tauware.de wrote: On 05.04.2014 08:46, Julien Cristau wrote: Control: tag -1 confirmed On Fri, Feb 14, 2014 at 13:27:53 +, Reinhard Tartler wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition I've prepared a new upstream release of libx264, and we need to rebuild all applications that link against it. AFAIUI, this transition should be rather smooth because it affects only a few packages. Feel free to upload to unstable. Uploaded, thanks. x264 now built on all architectures: https://buildd.debian.org/status/package.php?p=x264 Can you schedule the rebuilds now, please? -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caj0cceaj04r2jx3pyeilcjpybk0b1rb-lssxv5ccxz9rwvx...@mail.gmail.com
Bug#740210: transition: gpac
On 31.03.2014 15:27, Julien Cristau wrote: On Wed, Feb 26, 2014 at 22:37:41 +, Reinhard Tartler wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition I believe this should should be rather easy, as only libx264 links against gpac AFAIUI. I'd therefore suggest to do this transition together with #738978. As far as I can tell not even x264 links against gpac, so I don't think there's a need for us to track this, you can just go ahead and upload. Yes, it seems that x264 indeed links statically against libgpac, which doesn't seem right. I've had to add a patch to gpac to export a symbol on which x264 relies on, and was about to upload gpac to unstable to start this. Unfortunately, the current gpac package requires libav10, which is not in unstable. I'll therefore go with experimental for now. Any chance that we can start libav10 soon, ideally right after we got x264 through? Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53417e1e.8010...@tauware.de
Bug#738978: transition: x264
On 05.04.2014 08:46, Julien Cristau wrote: Control: tag -1 confirmed On Fri, Feb 14, 2014 at 13:27:53 +, Reinhard Tartler wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition I've prepared a new upstream release of libx264, and we need to rebuild all applications that link against it. AFAIUI, this transition should be rather smooth because it affects only a few packages. Feel free to upload to unstable. Uploaded, thanks. Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/534005cd.2020...@tauware.de
Bug#738978: transition: x264
On Sun, Mar 16, 2014 at 3:10 PM, Julien Cristau jcris...@debian.org wrote: Control: tag -1 moreinfo On Fri, Feb 14, 2014 at 13:27:53 +, Reinhard Tartler wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition I've prepared a new upstream release of libx264, and we need to rebuild all applications that link against it. AFAIUI, this transition should be rather smooth because it affects only a few packages. Are there API changes? Have the reverse deps been build tested? The following packages build just fine against the libx264-142 on my amd64 workstation: xpra gst-plugins-ugly1.0_1.2.3-2 handbrake jitsi libav libquicktime opal The following FTBFS: gst-plugins-ugly0.10 (#741848, unrelated to this transition) vlc seems to fail to build for reasons unrelated to x264 - possible there is something screwed up in my build system: configure.ac:31: error: possibly undefined macro: AM_SILENT_RULES If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:4140: error: possibly undefined macro: AC_CONFIG_FILES configure.ac:4187: error: possibly undefined macro: AM_COND_IF autoreconf: /usr/bin/autoconf failed with exit status: 1 -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ0cceb4f=6=rooqxzaymcnzvqodslqu6phk0ne4ljhe7ht...@mail.gmail.com
Bug#740444: Please remove xine-lib from jessie/testing
Package: xine-lib Severity: serious Hi, According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739453#17, the plan is to migrate all applications to xine-lib-1.2 anyways. This bug may or may not be reused to coordinate this transition. -- System Information: Debian Release: 7.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.11.0-17-generic (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140301154825.19382.76185.reportbug@debian-build
Bug#739079: transition: libav10
On Tue, Feb 18, 2014 at 4:48 PM, Moritz Mühlenhoff j...@inutil.org wrote: I made a rebuild and the transitions isn't ready to go at all. IMO the API changes are far too agressive; if 2/3 of all packages in the archive FTBFS, the affected APIs are clearly not that deprecated. I can understand the removal of ill-designed functions if it helps to streamline/robustify the code, but e.g. the removal of CODEC_ID* causes lots of churn for no measurable benefit. As Anton points out, the API changes are agressive, but done for good reason, most of which are documented in the transition guide. It is a wiki and will be extended as necessary. The CODEC_ID issue is indeed annoying, but kinda critical for C++ applications. Also note that the new names are supported even in debian/stable, so there is really no need for backwards compatibility here. Anyway, now two weeks after, I think things look much better now: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libav10;users=j...@debian.org Most packages have patches readily available or need a new upstream version. Note that more and more packages require libav10 to build, and are held back in experimental for this reason. The todo list of bugs without a patch is also shrinking rapidly: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libav10;users=j...@debian.org;exclude=tags%3Apatch%2C+fixed-upstream From the velocity of how fast packages are being patched, I think we are in a rather good position to start this transition. -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ0ccebgDO-ErLG_w9Q=gdcti18qs36znbfcmpwb3yj-tvs...@mail.gmail.com
Bug#740210: transition: gpac
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition I believe this should should be rather easy, as only libx264 links against gpac AFAIUI. I'd therefore suggest to do this transition together with #738978. Ben file: title = gpac; is_affected = .build-depends ~ libgpac-dev; is_good = .depends ~ libgpac3; is_bad = .depends ~ libgpac2; -- System Information: Debian Release: 7.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.11.0-17-generic (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140226223741.28423.83501.reportbug@debian-build
Re: Bug#739079: transition: libav10
On Sun, Feb 16, 2014 at 11:22 AM, Moritz Mühlenhoff j...@inutil.org wrote: Reinhard Tartler siret...@tauware.de schrieb: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, We have a new libav transition pending. Libav 10 is prepared in debian/experimental, and I've started to build packges against this new version; in fact, more or more packages require Libav 10 and the new APIs it provides. Is the alpha2 version in experimental final in terms of API deprecations? It should be. I intend to release and upload 10_beta1 to experimental by end of this weekend (tomorrow latest), and includes some additions that happened after alpha2 (i.e., there will be a shlibs, but no SONAME bump). Neverthless, I think it should be safe. -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caj0cceyobanw_fweqaznq6njm8tic8dqz6pemsezf4ehnqk...@mail.gmail.com
Bug#739079: transition: libav10
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, We have a new libav transition pending. Libav 10 is prepared in debian/experimental, and I've started to build packges against this new version; in fact, more or more packages require Libav 10 and the new APIs it provides. Unfortunately, this new release does break a number of packages in the debian archive. At upstream, we are concerned about this and have conducted a survey about the fallout here: https://etherpad.mozilla.org/mnrZI5XlxP Most projects have been fixed upstream already, some other are rather easy to fix (e.g., simple renames such as CODEC_ID - AV_CODEC_ID, etc.). In order to help with porting, Libav provides a migration guide here: https://wiki.libav.org/Migration/10 I sincerly do hope that this libav10 transition will not be as painful as libav9, but we do have a number of undermaintained packages in the archive that require upstream work. For those, I'd suggest to be a bit more aggressive with removing them from testing for the sake of having this transition done more quickly. Thanks for your assistance. Ben file: title = libav; is_affected = .depends ~ /lib(avcodec|avformat|avutil|device|filter)-dev/ is_good = .depends ~ /lib(avcodec55|avformat55|avutil53|device54|filter4)/ is_bad = .depends ~ /lib(avcodec54|avformat54|avutil52|device53|filter3)/ -- System Information: Debian Release: 7.2 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.11.0-15-generic (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140215174241.28890.37225.reportbug@debian-build
Bug#738978: transition: x264
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition I've prepared a new upstream release of libx264, and we need to rebuild all applications that link against it. AFAIUI, this transition should be rather smooth because it affects only a few packages. Thanks Ben file: title = x264; is_affected = .depends ~ libx264-133 | .depends ~ libx264-142; is_good = .depends ~ libx264-142; is_bad = .depends ~ libx264-133; -- System Information: Debian Release: 7.2 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.11.0-15-generic (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140214132753.3357.73373.reportbug@debian-build
Why doesn't aspectc++ migrate?
Hi, I wonder why the package aspect++ does not migrate. According to http://release.debian.org/migration/testing.pl?package=aspectc++, it seems to be because of missing arm builds. I expected that not to matter as the package is no longer in testing, but obviously I'm wrong. Upstream is aware of the issue but does not consider this a priority. I ask now what do you think would be the best course of action: a) adding some hint so that it migrates anyway b) change to source to include only i386 and amd64 in the Architecture line, as these are the only upstream supported architectures c) both a) and b) d) something else. Thanks for your help! -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caj0cceymzqxnevthn_temho4ioew26ubwr+47goakayls7e...@mail.gmail.com
Bug#725864: Bug#726433: Unknown option on the command line
On Wed, Oct 16, 2013 at 10:01 AM, Alessio Treglia ales...@debian.org wrote: On Wed, Oct 16, 2013 at 2:49 PM, Fabian Greffrath fab...@greffrath.com wrote: Cool, thanks! So, when will this be uploaded? Unfortunately not earlier than Wheezy's next point release. Alessio, I think there is a misunderstanding. AFAIUI, you can upload it now, but users would have to fetch it from proposed-updates until the next point release. Nevertheless, nothing is stopping you from uploading the fixed package now. At least that's my reading from Julien's mail. Cheers, Reinhard -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAJ0cceY78ra=sK-9Lj4p6NGu=3o7kv8q3v27qdt7oxwc33o...@mail.gmail.com
Bug#706798: some packages remaining for the transition.
On Wed, Oct 9, 2013 at 10:16 AM, shirish शिरीष shirisha...@gmail.com wrote: Hi all, It was nice to see updates happening on this transition but some packages are still to go through (it seems). I did the updates and only one of the obsolete packages have some dependencies which have not been updated to newer versions of library. None of the listed packages are currently in testing, so I guess that behavior is to be expected. Just remove those packages from your system. btw, gstreamer0.10-ffmpeg got replaced with gstreamer1.0-libav. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAJ0cceZb155ZH_UOX8U+FPc-4kwNwnm=pp_KPi_yJfcqOHQ=y...@mail.gmail.com
Bug#706798: transition: Libav 9
On Sun, Aug 18, 2013 at 1:15 AM, Julien Cristau jcris...@debian.org wrote: On Wed, Aug 14, 2013 at 16:18:38 +0200, Moritz Muehlenhoff wrote: Since libx264 is largely subsumed by libav, I think it makes very much sense to do them both at the same time. I am convinced that we will have less effort this way. OK, feel free to go ahead with both. (As discussed with Reinhard) Please add remove mplayer/2:1.0~rc4.dfsg1+svn34540-1 trying: -mplayer skipped: -mplayer (12 - 73) got: 5+0: i-5 * i386: devede, photofilmstrip, toonloop Should those rdeps be removed too? All three packages depend on mencoder, which has been deprecated and is essentially unmaintained by upstream for years. As I do have strong concerns that mencoder makes it for jessie release, I would suggest to remove mencoder, and all depending packages such as devede, photofilmstrip or toonloop, for now until some solution is found in order to speed up the libav9 transition. -- regards, Reinhard
Bug#706798: transition: Libav 9
On 13.08.2013 11:48, Julien Cristau wrote: On Sun, May 5, 2013 at 07:45:40 +0200, Reinhard Tartler wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition I would like to upload Libav 9 to unstable at your earliest convinience. To get an overview about the size and impact of the transition, I would like to drag your attention to the Ubuntu transition tracker page here: http://people.canonical.com/~ubuntu-archive/transitions/libav.html A number of packages are involved in both libav and libx264 transitions. Do you want to do both of them at the same time, or serialized? Since libx264 is largely subsumed by libav, I think it makes very much sense to do them both at the same time. I am convinced that we will have less effort this way. Cheers, Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1b3d5e3b9ac0605a9e1f5545de744...@tauware.de
Bug#706798: transition: Libav 9
On Di, Aug 13, 2013 at 14:30:03 (CEST), Julien Cristau wrote: On Tue, Aug 13, 2013 at 12:56:46 +0200, Reinhard Tartler wrote: On 13.08.2013 11:48, Julien Cristau wrote: On Sun, May 5, 2013 at 07:45:40 +0200, Reinhard Tartler wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition I would like to upload Libav 9 to unstable at your earliest convinience. To get an overview about the size and impact of the transition, I would like to drag your attention to the Ubuntu transition tracker page here: http://people.canonical.com/~ubuntu-archive/transitions/libav.html A number of packages are involved in both libav and libx264 transitions. Do you want to do both of them at the same time, or serialized? Since libx264 is largely subsumed by libav, I think it makes very much sense to do them both at the same time. I am convinced that we will have less effort this way. OK, feel free to go ahead with both. I'm currently uploading libav9 to unstable, but I head to weaken the dependencies for libx264, opencv and frei0r, which all (but frei0r) in turn require libav9 to build AFAIUI: http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libav.git;a=commit;h=79cad71e56cb2ff50631558f663c8582469a0460 Next steps involve bringing these three packages from experimental to unstable, and then rebuild libav against them. I'll contact you if binNMUs of libav9 are possible, or if a sourceful upload is necessary anyways. In any case, thank you for scheduling this transition and your great work on bringing jessie along! Cheers, Reinhard -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87li45paiu@faui43f.informatik.uni-erlangen.de
Bug#706798: transition: Libav 9
On Sun, Jun 2, 2013 at 11:32 AM, Julien Cristau jcris...@debian.org wrote: Procedural question: Are these bugs blockers to start the transition? Does the release team require all of them to be fixed in experimental (via MU or NMUs) before uploading libav9 to unstable? Not necessarily, but we'd like to know they're not going to sit unfixed for months. So at least having a patch tag would be good. I've revisted all those blockers, and all have a patch provided with two notable exceptions: - audacity, for which I know that Benjamin is working on that - quotecom, which had its last maintainer update in 2011, I'd suggest to remove it from testing for now. Any chance we can start the transition soon? -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAJ0cceY_X72UZQgM5SBRVKWmRPmc8+D88GPqYgv+14m=jzn...@mail.gmail.com
Re: Bug#706798: transition: Libav 9
On Sun, Jun 2, 2013 at 1:27 AM, Sebastian Ramacher sramac...@debian.org wrote: Control: block -1 by 692980 694131 693560 693639 693641 692809 692505 For the record, the following packages are known to FTBFS against libav 9: audacious-plugins: #692505 audacity: #692809 electricsheep: #692980 qutecom: #693560 vice: #693641 vtk: #693639 zoneminder: #694131 Setting them as blockers to keep track. Procedural question: Are these bugs blockers to start the transition? Does the release team require all of them to be fixed in experimental (via MU or NMUs) before uploading libav9 to unstable? -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAJ0ccebHujKKHPO40nGw-RMqfhXrCuA_4eJ12Q3zOiMect=c...@mail.gmail.com
Re: Incomplete ben file for libav9 transition?
On Thu, May 30, 2013 at 8:54 AM, José Manuel Santamaría Lema panfa...@gmail.com wrote: Hello Reinhard, Reinhard Tartler siret...@gmail.com On Wed, May 29, 2013 at 12:18 AM, José Manuel Santamaría Lema panfa...@gmail.com wrote: Hello, unless I'm missing something, I think in the ben file you may have missed: - In Bad: packages depending on libavcodec-extra-53, libavcodec-extra-53 and libavutil-extra-51 - In Good: packages depending on libavcodec-extra-54, libavcodec-extra-54 and libavutil-extra-52 Packages are not supposed to depend on libavcodec-extra-53 or libavcodec-extra-54, unless really really necessary. Can you show examples that explicitly depend on the -extra- variants, and only them? I only know of devede, and would like to know if they are more offenders. With this ben query; ben query .depends ~/libavcodec-extra-53/ ! .depends ~/libavcodec53/ -s Package,Version,Source,Architecture,Depends * I found out that dvd-slideshow is also affected. I tried similar queries for avformat and avutil but I found nothing. I have uplodaded a new libav package to experimental that contains the libavcodec-extra meta-package, so packages can depend on the extra functionality in a robust manner. Please note that only GPLv3 application can do so, GPLv2 (probably) must not do so. Also I would like to mention some things more, which you may find interesting: for some reason when you build a package with sbuild and the aptitude resolver you don't get a depend on libavcodec53 | libavcodec-extra-53, but a depend on the extra package and only the extra package. See for instance amarok in experimental for amd64. This happens when the sbuild aptitude resolver doesn't install libavcodec53. I've seen that as well, and I think this may be problematic. I've tried to express this issue in the past, but was unable to explain why this is a problem. Since then, I'm waiting for someone else to see the license-wise problem that arise here. It also happened to me randomly when building other KDE 4.10 packages, such as src:nepomuk-core and src:ffmpegthumbs. I realized about this problem because I'm maintaining an unofficial repository with KDE packages for debian similar to the old qt-kde.debian.net. A couple of users told me that their upgrades wanted to remove amarok and other stuff. This problem happened only with apt-get, but not with aptitude, but since official debian KDE 4.10 packages from experimental are difficult to install/upgrade with apt-get, and the current debian qt/kde team stopped using qt-kde.debian.net (which would made the upgrades easier with apt-get and easier in general), nobody in debian realized about this problem. can you explain why this is a problem? To workaround the problem I added libavcodec53 to the build depends of my customized packages amarok, nepomuk-core and ffmpegthumbs, thus I'm getting the correct depends, even while I'm building my packages with sbuild and the aptitude resolver. I do not think that this is a good solution. Cheers, Reinhard -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caj0cceawgbxk2nsyz4vnaydm313gvygvozpxfv+v29ljvzh...@mail.gmail.com
Re: Incomplete ben file for libav9 transition?
On Wed, May 29, 2013 at 12:18 AM, José Manuel Santamaría Lema panfa...@gmail.com wrote: Hello, unless I'm missing something, I think in the ben file you may have missed: - In Bad: packages depending on libavcodec-extra-53, libavcodec-extra-53 and libavutil-extra-51 - In Good: packages depending on libavcodec-extra-54, libavcodec-extra-54 and libavutil-extra-52 Packages are not supposed to depend on libavcodec-extra-53 or libavcodec-extra-54, unless really really necessary. Can you show examples that explicitly depend on the -extra- variants, and only them? I only know of devede, and would like to know if they are more offenders. -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAJ0cceaAjpRp+=xwysod4nbsue5kp2si_mxgen82lngqtuu...@mail.gmail.com
Bug#709039: transition: x264
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, We would like to upload a new version of libx264 to unstable. There are no API changes, but a few additional defines that requires acouple of rebuilds. Ben file: title = x264; is_affected = .depends ~ libx264-129 | .depends ~ libx264-130; is_good = .depends ~ libx264-130; is_bad = .depends ~ libx264-129; -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130520114606.28363.53211.reportbug@faui43f
Bug#709039: transition: x264
On Mo, Mai 20, 2013 at 21:26:49 (CEST), Adam D. Barratt wrote: On Mon, 2013-05-20 at 13:46 +0200, Reinhard Tartler wrote: title = x264; is_affected = .depends ~ libx264-129 | .depends ~ libx264-130; is_good = .depends ~ libx264-130; is_bad = .depends ~ libx264-129; libx264-129 only exists in experimental. Should be that be libx264-123 instead? Ups, you're totally right, my bad. Please update the 'is_bad' line accordingly. Thanks Cheers, Reinhard -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871u91pgud@faui43f.informatik.uni-erlangen.de
Bug#706798: transition: Libav 9
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition I would like to upload Libav 9 to unstable at your earliest convinience. To get an overview about the size and impact of the transition, I would like to drag your attention to the Ubuntu transition tracker page here: http://people.canonical.com/~ubuntu-archive/transitions/libav.html Note that the transition has not started yet, most of the packages have already been transitioned either in experimental or, on the ubuntu side, the motumedia PPA. The transition parameters also apply to debian, so I'd really appreciate if you could setup a similar page on http://release.debian.org/transitions/ as well. Congratualations on the wheezy release and Cheers, Reinhard -- System Information: Debian Release: 6.0.7 APT prefers oldstable APT policy: (500, 'oldstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130505054540.32189.22948.report...@vamos2c.informatik.uni-erlangen.de
Bug#691791: unblock: libav/6:0.8.4-1
On Mon, Oct 29, 2012 at 7:12 PM, Moritz Muehlenhoff j...@debian.org wrote: Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package libav. It fixes multiple security issues: CVE-2012-2772 CVE-2012-2775 CVE-2012-2776 CVE-2012-2777 CVE-2012-2779 CVE-2012-2784 CVE-2012-2786 CVE-2012-2787 CVE-2012-2788 CVE-2012-2789 CVE-2012-2790 CVE-2012-2793 CVE-2012-2794 CVE-2012-2796 CVE-2012-2798 CVE-2012-2800 CVE-2012-2801 CVE-2012-2802 We also used to ship the libav/ffmpeg micro releases in stable-security for Squeeze. unblock libav/6:0.8.4-1 As maintainer of the package, I strongly support this unblock request. The patches have been very conservatively chosen to minimize the risk of regressions. In general, I found it very hard to tell what of the issues were security relevant and what not, which explain why it took me so much time to get the release done. If you have any further questions, do not hesitate to ask! -- regards, Reinhard
Re: Bug#688578: libbluray1: libbluray missling pkg-config build dependency
On Sun, Sep 23, 2012 at 10:47 PM, Michael Marineau m...@marineau.org wrote: If pkg-config is not installed the libbluray configure script will happily disalbe libxml2/metadata support without a fuss. This is what apears to be what happened do the current version in testing, 0.2.2-1. By chance the current experimental version, 0.2.3-1, was built with libxml2 support. Pretty simple fix to avoid future troublesome builds like 0.2.2-1. :-) diff --git a/debian/control b/debian/control index 4dc8013..04a0a77 100644 --- a/debian/control +++ b/debian/control @@ -18,6 +18,7 @@ Build-Depends: debhelper (= 8.1.3~), texlive-latex-extra, latex-xcolor, texlive-fonts-recommended, + pkg-config, Standards-Version: 3.9.3 Homepage: http://www.videolan.org/developers/libbluray.html Vcs-Git: git://git.debian.org/git/pkg-multimedia/libbluray.git Dear release team, would an upload to unstable with the change above to be acceptable for an unblock to fix this bug in wheezy? -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caj0cceylrhtrk01qado74o-hwbco9a9yqzprmiacp5owdeq...@mail.gmail.com
Bug#686244: unblock: libav/6:0.8.3-7
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package libav
The new package compresses with xz now (Bug #683895). The package
libav-regular-dbg is dropped as it does not necessary for transitional
purposes. Also, the fix for #679542 was incomplete, this package
revision fixes it for good.
unblock libav/6:0.8.3-7
Please find the debdiff attached. Thanks for your time.
Cheers,
Reinhard
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-2-686-pae (SMP w/1 CPU core)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff --git a/debian/changelog b/debian/changelog
index cfba07c..6cf6c3a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+libav (6:0.8.3-7) unstable; urgency=low
+
+ [ Fabian Greffrath ]
+ * Fix generation of shlibs file not only for libavcodec*, but for all the
+other library packages as well. Really closes: #679542
+ * Use xz compression for binary packages, thanks Ansgar Burchardt
+(Closes: #683895).
+
+ [ Reinhard Tartler ]
+ * use EPOCH macro in SHLIBS_VERSION
+ * Drop the package 'libav-regular-dbg'. It was not included in squeeze.
+
+ -- Reinhard Tartler siret...@tauware.de Sat, 25 Aug 2012 11:08:48 +0200
+
libav (6:0.8.3-6) unstable; urgency=low
* Clarify the changes in the 6:0.8.3-5 upload, as discussed in bug
diff --git a/debian/control b/debian/control
index 43c4f1a..799e8c4 100644
--- a/debian/control
+++ b/debian/control
@@ -123,11 +123,9 @@ Priority: extra
Architecture: any
Replaces:
ffmpeg-dbg ( 6:0.8.3-5),
- libav-regular-dbg ( 6:0.8.3-5),
libav-extra-dbg ( 6:0.8.3-5)
Breaks:
ffmpeg-dbg ( 6:0.8.3-5),
- libav-regular-dbg ( 6:0.8.3-5),
libav-extra-dbg ( 6:0.8.3-5)
Depends:
ffmpeg (= ${binary:Version}),
@@ -148,19 +146,6 @@ Description: Debug symbols for Libav related packages
Most people will not need this package. Please install it to produce useful
stacktraces to help debugging the Libav library.
-Package: libav-regular-dbg
-Section: oldlibs
-Priority: extra
-Architecture: any
-Depends:
- libav-dbg,
- ${misc:Depends}
-Description: Debug symbols for Libav related packages (transitional package)
- Libav is a complete, cross-platform solution to decode, encode, record,
- convert and stream audio and video.
- .
- This package serves as a transitional package to libav-dbg.
-
Package: libav-extra-dbg
Section: oldlibs
Priority: extra
diff --git a/debian/rules b/debian/rules
index fa5a4a0..697dd11 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,7 +4,7 @@ EPOCH=6:
DEB_SOURCE := $(shell dpkg-parsechangelog | sed -n 's/^Source: //p')
DEB_VERSION := $(shell dpkg-parsechangelog | sed -n 's/^Version: //p')
UPSTREAM_VERSION := $(shell echo $(DEB_VERSION) | sed -r 's/[^:]+://; s/-[^-]+$$//')
-SHLIBS_VERSION := 6:0.8.3-1~
+SHLIBS_VERSION := $(EPOCH)0.8.3-1~
# these package do not build -extra variants
LIB_PKGS := $(shell sed -nr 's/^Package:[[:space:]]*(lib(avutil|avdevice|avformat|avfilter|postproc|swscale)[0-9]+)[[:space:]]*$$/\1/p' debian/control)
@@ -172,7 +172,7 @@ binary-arch: build install
dh_strip --dbg-package=libav-dbg
for pkg in $(LIB_PKGS) $(LIB_EXTRA_PKGS); do \
- dh_makeshlibs -p$$pkg -V$$pkg (= $(DEB_VERSION)); \
+ dh_makeshlibs -p$$pkg -V$$pkg (= $(SHLIBS_VERSION)); \
done
for pkg in $(LIB_PKGS2); do \
upkg=$$(echo $$pkg | sed -r 's/([0-9]+)$$/-extra-\1/'); \
@@ -182,7 +182,7 @@ binary-arch: build install
dh_installdeb
dh_gencontrol
dh_md5sums
- dh_builddeb
+ dh_builddeb -- -Zxz
binary: binary-indep binary-arch
Bug#683247: Bug#683030: unblock: vlc/2.0.3-1
tags 683247 -moreinfo retitle 683247 unblock libav_6:0.8.3-6 stop On Mon, Jul 30, 2012 at 2:17 PM, Adam D. Barratt a...@adam-barratt.org.uk wrote: On 30.07.2012 08:08, Reinhard Tartler wrote: I intend to work on a new upload that incorporates your suggestions for clarifying the debian/changelog file this week. If you don't mind, I'd leave the doxygen and the Provides: ffmpeg changes as-is. Additionally, I intend to change ffmpeg-dbg from Arch: any to arch: all for consistency with libav-extra-dbg (both are empty, transitional packages). That sounds fine to me; thanks. Please let us know (and retitle the libav unblock bug appropriately) once that's been done. I'm doing so with this email. Please consider adjusting the time that is required for migration. Please also note that in additional to the above, I've also included a fix for bug #679542, which prevents the migration of the vlc package. AFAIUI, if vlc would be rebuild against this new version of libav (e.g., by scheduling binNMUs), Britney should let vlc migrate independently of libav. But that might be just a waste of ressources, so your call. -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAJ0ccea-0GFeNGO86W6nyoJkAwZaLFzE1Dns4KVQZamOknfU=a...@mail.gmail.com
