Bug#1033839: Packaging docker 24.0.9

[Reinhard Tartler]

status update:

* Picked up the proposed changes Arnaud, I think using dh-golang is an
excellent idea
* seems our google-grpc version in sid is too old, but there is a newer one
in experimental, so let's use that for now
* tried to build against etcd server in sid, doesn't seem to work though
* updated containerd/typeurl and mitchellh/hashstructure in experimental. I
believe both should be good for sid, but I didn't check whether the changes
break existing packages. That needs to be done before uploading docker.io
24 to sid


Currently fails to build with:

src/github.com/docker/docker/cmd/dockerd/service_unsupported.go
cd _build && go install -trimpath -v -p 8 -tags "apparmor seccomp journald"
-buildmode=pie -ldflags "-w -X
github.com/docker/docker/dockerversion.Version=24.0.9+dfsg1 -X
github.com/docker/docker/dockerversion.GitCommit=fca702d -X
github.com/docker/docker/dockerversion.BuildTime=2024-05-11T18:30:26.0+00:00
-X github.com/docker/docker/dockerversion.PlatformName= -X
github.com/docker/docker/dockerversion.ProductName=docker -X
github.com/docker/docker/dockerversion.DefaultProductLicense="
github.com/docker/docker/cmd/dockerd
src/
github.com/docker/docker/vendor/github.com/moby/swarmkit/v2/api/raft.pb.go:12:2:
cannot find package "go.etcd.io/etcd/raft/v3/raftpb" in any of:
/<>/_build/src/
github.com/docker/docker/vendor/go.etcd.io/etcd/raft/v3/raftpb (vendor tree)
/usr/lib/go-1.22/src/go.etcd.io/etcd/raft/v3/raftpb (from $GOROOT)
/<>/_build/src/go.etcd.io/etcd/raft/v3/raftpb (from $GOPATH)
src/github.com/docker/docker/libcontainerd/shimopts/convert.go:4:2: cannot
find package "
github.com/Microsoft/hcsshim/cmd/containerd-shim-runhcs-v1/options" in any
of:
/<>/_build/src/
github.com/docker/docker/vendor/github.com/Microsoft/hcsshim/cmd/containerd-shim-runhcs-v1/options
(vendor tree)
/usr/lib/go-1.22/src/
github.com/Microsoft/hcsshim/cmd/containerd-shim-runhcs-v1/options (from
$GOROOT)
/<>/_build/src/
github.com/Microsoft/hcsshim/cmd/containerd-shim-runhcs-v1/options (from
$GOPATH)
src/
github.com/docker/docker/vendor/github.com/moby/swarmkit/v2/manager/state/raft/storage/storage.go:13:2:
cannot find package "go.etcd.io/etcd/client/pkg/v3/fileutil" in any of:
/<>/_build/src/
github.com/docker/docker/vendor/go.etcd.io/etcd/client/pkg/v3/fileutil
(vendor tree)
/usr/lib/go-1.22/src/go.etcd.io/etcd/client/pkg/v3/fileutil (from $GOROOT)
/<>/_build/src/go.etcd.io/etcd/client/pkg/v3/fileutil (from
$GOPATH)
src/
github.com/docker/docker/vendor/github.com/moby/swarmkit/v2/manager/state/raft/storage/snapwrap.go:12:2:
cannot find package "go.etcd.io/etcd/server/v3/etcdserver/api/snap" in any
of:
/<>/_build/src/
github.com/docker/docker/vendor/go.etcd.io/etcd/server/v3/etcdserver/api/snap
(vendor tree)
/usr/lib/go-1.22/src/go.etcd.io/etcd/server/v3/etcdserver/api/snap (from
$GOROOT)
/<>/_build/src/go.etcd.io/etcd/server/v3/etcdserver/api/snap
(from $GOPATH)
src/
github.com/docker/docker/vendor/github.com/moby/swarmkit/v2/manager/state/raft/storage/storage.go:16:2:
cannot find package "go.etcd.io/etcd/server/v3/wal" in any of:
/<>/_build/src/
github.com/docker/docker/vendor/go.etcd.io/etcd/server/v3/wal (vendor tree)
/usr/lib/go-1.22/src/go.etcd.io/etcd/server/v3/wal (from $GOROOT)
/<>/_build/src/go.etcd.io/etcd/server/v3/wal (from $GOPATH)
src/
github.com/docker/docker/vendor/github.com/moby/swarmkit/v2/manager/state/raft/storage/storage.go:17:2:
cannot find package "go.etcd.io/etcd/server/v3/wal/walpb" in any of:
/<>/_build/src/
github.com/docker/docker/vendor/go.etcd.io/etcd/server/v3/wal/walpb (vendor
tree)
/usr/lib/go-1.22/src/go.etcd.io/etcd/server/v3/wal/walpb (from $GOROOT)
/<>/_build/src/go.etcd.io/etcd/server/v3/wal/walpb (from
$GOPATH)
src/
github.com/docker/docker/vendor/github.com/moby/swarmkit/v2/manager/state/raft/transport/peer.go:16:2:
cannot find package "go.etcd.io/etcd/raft/v3" in any of:
/<>/_build/src/
github.com/docker/docker/vendor/go.etcd.io/etcd/raft/v3 (vendor tree)
/usr/lib/go-1.22/src/go.etcd.io/etcd/raft/v3 (from $GOROOT)
/<>/_build/src/go.etcd.io/etcd/raft/v3 (from $GOPATH)
src/
github.com/docker/docker/vendor/github.com/moby/swarmkit/v2/manager/state/raft/raft.go:32:2:
cannot find package "go.etcd.io/etcd/pkg/v3/idutil" in any of:
/<>/_build/src/
github.com/docker/docker/vendor/go.etcd.io/etcd/pkg/v3/idutil (vendor tree)
/usr/lib/go-1.22/src/go.etcd.io/etcd/pkg/v3/idutil (from $GOROOT)
/<>/_build/src/go.etcd.io/etcd/pkg/v3/idutil (from $GOPATH)
dh_auto_build: error: cd _build && go install -trimpath -v -p 8 -tags
"apparmor seccomp journald" -buildmode=pie -ldflags "-w -X
github.com/docker/docker/dockerversion.Version=24.0.9+dfsg1 -X
github.com/docker/docker/dockerversion.GitCommit=fca702d -X
github.com/docker/docker/dockerversion.BuildTime=2024-05-11T18:30:26.0+00:00
-X github.com/docker/docker/dockerversion.PlatformName= -X
github.com/docker/docker/dockerversion.ProductName=docker -X
github.com/docker/docker/dockerversion.DefaultProductLicense="

Bug#1033839: Packaging docker 24.0.9

[Reinhard Tartler]

On Fri, May 17, 2024 at 3:06 PM Tianon Gravi  wrote:

> That's a little bit of a separate concern from what I was talking about
> (Moby own versions vs code dependencies).
>
> In short, no, the upstream project does not currently have any "LTS"
> branches (and never really had anything *super* long term outside of the
> enterprise edition that wasn't open source -- the longest I recall on the
> open source side was somewhere around four months).
>
> The closest thing upstream to LTS right now is probably the 23.x
> branch/release line where Mirantis is maintaining their currently supported
> version with the support/assistance/blessing of the upstream community.
>
> AFAIK, the 24.x branch is effectively already EOL.
>
>
Just to clarify and for the avoidance of doubt, I picked 24.0.9 because I
understand this is the version that is supposed to work with the version of
containerd we currently have in unstable. Obviously packaging supported
versions of docker/containerd is preferable, but since this is already a
daunting task, I opted for this older version to not make the task
more complicated than it needs to be.


-- 
regards,
Reinhard

Bug#1033839: Packaging docker 24.0.9

[Reinhard Tartler]

Hi,

copying everyone currently listed as co-maintainer of the docker.io package
in Debian.

I've decided to give this thing a stab. It seems Debian currently ships the
same minor upstream version of docker.io 20.10 as we had in unstable, and
more and more packages (such as podman) require significantly newer
versions  of docker. This is starting to do a serious disservice to our
users.

My current work in progress lives in
https://salsa.debian.org/go-team/packages/docker/-/tree/siretart/docker24?ref_type=heads.
So far, I've:

- identified that libnetwork got merged into gh:moby/moby, so I've removed
references from the packaging
- tried to follow README.source as much as possible
- identified vendored sources and updated the Files-Excluded fields and
debian/copyright as appropriate
- refreshed patches against the new upstream version
- identified circular dependencies and chose vendored versions to unbreak
them.

What I would appreciate help with:

- reviewing what I've done. This is a very complex package that is done in
a style that I'm not used to work with
- help getting it to build (it currently doesn't, I suspect because at
least some dependencies in debian are too old. I guess using vendored
copies is the most expedient way to go about this?
- update debian/copyright for new code additions
- identify and drop unnecessary dependencies from debian/control.

Thank you so much for your support and assistance!

-rt


-- 
regards,
Reinhard

Bug#1070727: reportbug: podman does not run wasm/wasi images because of missing crun-wasm - easy fix

[Reinhard Tartler]

On Thu, May 16, 2024 at 7:50 AM Faidon Liambotis 
wrote:

> Control: reassign -1 crun
> Control: retitle -1 Ship the crun-wasm runtime
> Control: severity -1 wishlist
> Control: forwarded -1 https://github.com/containers/crun/issues/1468
>
> On Sun, May 12, 2024 at 03:34:42PM +0300, Faidon Liambotis wrote:
> > Perhaps it's worth bringing it up with both crun and podman upstreams, I
> > don't think we're going to be the only distro dealing with this.  (I can
> > take care of that.)
>
> We have a little more clarity from Giuseppe. I'll work on shipping
> crun-wasm on the next crun upload. (Still debating whether I should ship
> it in a different package or not.)
>
>
That's awesome, thanks for reaching out to upstream and getting input!

As for what package should ship the symlink: I don't see a reason
why you wouldn't have it in the same package. It could make sense
if crun-wasm required additional dependencies that wouldn't be required
otherwise. Or if its presence somehow degraded / limited the wasm
functionality.

It might make sense to ship the symlink in the crun-package and have a
Provides: crun-wasm relationship.


-- 
regards,
Reinhard

Bug#1069310: marked as pending in golang-github-hanwen-go-fuse

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #1069310 in golang-github-hanwen-go-fuse reported by you has been fixed in 
the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/go-team/packages/golang-github-hanwen-go-fuse/-/commit/732cc0974fc75d4b9a94a44e0ad49b03449a098a


Fix build failures on mips for dependant packages, Closes: #1069310


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1069310

Bug#1071035: marked as pending in golang-github-fatih-semgroup

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #1071035 in golang-github-fatih-semgroup reported by you has been fixed in 
the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/go-team/packages/golang-github-fatih-semgroup/-/commit/99dab73ab3aace348e6c6eb0ff0baf2ef98de7cd


Fix Test failure FAIL: TestGroup_deadlock, Closes: #1071035


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1071035

Bug#1071038: golang-google-api: timeout in test TestBundlerTimeBasedFlushDeadlock

[Reinhard Tartler]

Control: tag -1 patch

On 5/13/24 9:15 AM, Reinhard Tartler wrote:

I suspect this issue may be triggered by the upload of golang-golang-x-sync 
0.7.0 to sid. #1071035 is another issue related to code changes in the 
semaphore implmentation.

in google-api-go, I've found exactly one upstream commit that we don't 
currently have in debian in the 'support/bundler' package:

https://github.com/googleapis/google-api-go-client/commit/8d0b2b5bc50e98e2865818bee89911d3348b43dc

The commit message talks about a bugfix in the http/transport, but the commit 
also update the x/sync package 0.7 and increases a timeout. I wonder whether 
bumping the timeout would be the thing to do in debian as well?

I'll try later when I have a better internet connection.



Please consider the attached patch that I've extracted from the above upstream 
commit. This reliably fixes the FTBFS for me.Index: golang-google-api/support/bundler/bundler_test.go
===
--- golang-google-api.orig/support/bundler/bundler_test.go
+++ golang-google-api/support/bundler/bundler_test.go
@@ -394,7 +394,7 @@ func TestBundlerTimeBasedFlushDeadlock(t
 	b.BundleByteThreshold = math.MaxInt32
 
 	ctx, cancel := context.WithCancel(context.Background())
-	time.AfterFunc(1*time.Second, cancel)
+	time.AfterFunc(15*time.Second, cancel)
 
 	add := func(i int) {
 		for j := 0; j < iterations; j++ {

Bug#1071038: golang-google-api: timeout in test TestBundlerTimeBasedFlushDeadlock

[Reinhard Tartler]

I suspect this issue may be triggered by the upload of golang-golang-x-sync 
0.7.0 to sid. #1071035 is another issue related to code changes in the 
semaphore implmentation.

in google-api-go, I've found exactly one upstream commit that we don't 
currently have in debian in the 'support/bundler' package:

https://github.com/googleapis/google-api-go-client/commit/8d0b2b5bc50e98e2865818bee89911d3348b43dc

The commit message talks about a bugfix in the http/transport, but the commit 
also update the x/sync package 0.7 and increases a timeout. I wonder whether 
bumping the timeout would be the thing to do in debian as well?

I'll try later when I have a better internet connection.

Bug#1071035: FAIL: TestGroup_deadlock

[Reinhard Tartler]

Control: reassign -1 golang-golang-x-sync 0.7.0
Control: affects -1 golang-github-fatih-semgroup

This seems to be related to upgrading golang-golang-x-sync to 0.7.0.

This is how to reproduce is using pristine upstream sources:

siretart@x1:/tmp/docker.io $ git clone https://github.com/fatih/semgroup
Cloning into 'semgroup'...
remote: Enumerating objects: 46, done.
remote: Counting objects: 100% (46/46), done.
remote: Compressing objects: 100% (37/37), done.
remote: Total 46 (delta 23), reused 21 (delta 7), pack-reused 0
Receiving objects: 100% (46/46), 10.49 KiB | 10.49 MiB/s, done.
Resolving deltas: 100% (23/23), done.
siretart@x1:/tmp/docker.io $ cd ./semgroup/
siretart@x1:/tmp/docker.io/semgroup $ go mod edit -require 
golang.org/x/sync@v0.7.0
siretart@x1:/tmp/docker.io/semgroup $ go mod tidy
siretart@x1:/tmp/docker.io/semgroup $ go test -vet=off -v -p 8 
github.com/fatih/semgroup
=== RUN   TestGroup_single_task
--- PASS: TestGroup_single_task (0.00s)
=== RUN   TestGroup_multiple_tasks
--- PASS: TestGroup_multiple_tasks (0.00s)
=== RUN   TestGroup_multiple_tasks_errors
--- PASS: TestGroup_multiple_tasks_errors (0.00s)
=== RUN   TestGroup_deadlock
semgroup_test.go:92: error should be:
1 error(s) occurred:
* couldn't acquire semaphore: context canceled
got:
2 error(s) occurred:
* couldn't acquire semaphore: context canceled
* couldn't acquire semaphore: context canceled
--- FAIL: TestGroup_deadlock (0.00s)
=== RUN   TestGroup_multiple_tasks_errors_Is
--- PASS: TestGroup_multiple_tasks_errors_Is (0.00s)
=== RUN   TestGroup_multiple_tasks_errors_As
--- PASS: TestGroup_multiple_tasks_errors_As (0.00s)
=== RUN   ExampleGroup_parallel
--- PASS: ExampleGroup_parallel (0.00s)
=== RUN   ExampleGroup_withErrors
--- PASS: ExampleGroup_withErrors (0.00s)
FAIL
FAILgithub.com/fatih/semgroup   0.002s
FAIL

Bug#1071035: FAIL: TestGroup_deadlock

[Reinhard Tartler]

Control: reassign -1 golang-golang-x-sync 0.7.0
Control: affects -1 golang-github-fatih-semgroup

This seems to be related to upgrading golang-golang-x-sync to 0.7.0.

This is how to reproduce is using pristine upstream sources:

siretart@x1:/tmp/docker.io $ git clone https://github.com/fatih/semgroup
Cloning into 'semgroup'...
remote: Enumerating objects: 46, done.
remote: Counting objects: 100% (46/46), done.
remote: Compressing objects: 100% (37/37), done.
remote: Total 46 (delta 23), reused 21 (delta 7), pack-reused 0
Receiving objects: 100% (46/46), 10.49 KiB | 10.49 MiB/s, done.
Resolving deltas: 100% (23/23), done.
siretart@x1:/tmp/docker.io $ cd ./semgroup/
siretart@x1:/tmp/docker.io/semgroup $ go mod edit -require 
golang.org/x/sync@v0.7.0
siretart@x1:/tmp/docker.io/semgroup $ go mod tidy
siretart@x1:/tmp/docker.io/semgroup $ go test -vet=off -v -p 8 
github.com/fatih/semgroup
=== RUN   TestGroup_single_task
--- PASS: TestGroup_single_task (0.00s)
=== RUN   TestGroup_multiple_tasks
--- PASS: TestGroup_multiple_tasks (0.00s)
=== RUN   TestGroup_multiple_tasks_errors
--- PASS: TestGroup_multiple_tasks_errors (0.00s)
=== RUN   TestGroup_deadlock
semgroup_test.go:92: error should be:
1 error(s) occurred:
* couldn't acquire semaphore: context canceled
got:
2 error(s) occurred:
* couldn't acquire semaphore: context canceled
* couldn't acquire semaphore: context canceled
--- FAIL: TestGroup_deadlock (0.00s)
=== RUN   TestGroup_multiple_tasks_errors_Is
--- PASS: TestGroup_multiple_tasks_errors_Is (0.00s)
=== RUN   TestGroup_multiple_tasks_errors_As
--- PASS: TestGroup_multiple_tasks_errors_As (0.00s)
=== RUN   ExampleGroup_parallel
--- PASS: ExampleGroup_parallel (0.00s)
=== RUN   ExampleGroup_withErrors
--- PASS: ExampleGroup_withErrors (0.00s)
FAIL
FAILgithub.com/fatih/semgroup   0.002s
FAIL

Bug#1071035: FAIL: TestGroup_deadlock

[Reinhard Tartler]

Control: tag -1 patch

I've filed https://github.com/fatih/semgroup/pull/7 as a workaround.

Anthony, what's your take on this, should we include that patch in the Debian 
Package?

-rt

From bb5f94c0d8e6ddf1f24f673303d73e84c285e1ac Mon Sep 17 00:00:00 2001
From: Reinhard Tartler 
Date: Mon, 13 May 2024 08:31:03 -0400
Subject: [PATCH] chore: bump x/sync to 0.7

Note that this version changes the behavior of semaphore slightly.
After 
https://cs.opensource.google/go/x/sync/+/14be23e5b48bec28285f8a694875175ecacfddb3
the semaphore package will reliably raise errors for both go routines

change the test to test for a substring to be more relaxed in case that
behavior gets reverted
---
 go.mod   | 2 +-
 go.sum   | 4 ++--
 semgroup_test.go | 8 
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/go.mod b/go.mod
index 1a651d6..5926c6b 100644
--- a/go.mod
+++ b/go.mod
@@ -2,4 +2,4 @@ module github.com/fatih/semgroup
 
 go 1.17
 
-require golang.org/x/sync v0.0.0-20210220032951-036812b2e83c

+require golang.org/x/sync v0.7.0
diff --git a/go.sum b/go.sum
index 5c00efd..e8ef4a3 100644
--- a/go.sum
+++ b/go.sum
@@ -1,2 +1,2 @@
-golang.org/x/sync v0.0.0-20210220032951-036812b2e83c 
h1:5KslGYwFpkhGh+Q16bwMP3cOontH8FOep7tGV86Y7SQ=
-golang.org/x/sync v0.0.0-20210220032951-036812b2e83c/go.mod 
h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
+golang.org/x/sync v0.7.0 h1:YsImfSBoP9QPYL0xyKJPq0gcaJdG3rInoqxTWbfQu9M=
+golang.org/x/sync v0.7.0/go.mod h1:Czt+wKu1gCyEFDUtn0jG5QVvpJ6rzVqr5aXyt9drQfk=
diff --git a/semgroup_test.go b/semgroup_test.go
index 255206d..3c90bf6 100644
--- a/semgroup_test.go
+++ b/semgroup_test.go
@@ -4,6 +4,7 @@ import (
"context"
"errors"
"os"
+   "strings"
"sync"
"testing"
 )
@@ -85,11 +86,10 @@ func TestGroup_deadlock(t *testing.T) {
t.Fatalf("g.Wait() should return an error")
}
 
-	wantErr := `1 error(s) occurred:

-* couldn't acquire semaphore: context canceled`
+   wantErr := `couldn't acquire semaphore: context canceled`
 
-	if wantErr != err.Error() {

-   t.Errorf("error should be:\n%s\ngot:\n%s\n", wantErr, 
err.Error())
+   if !strings.Contains(err.Error(), wantErr) {
+   t.Errorf("error should contain:\n%s\ngot:\n%s\n", wantErr, 
err.Error())
}
 }
 

Bug#1071035: FAIL: TestGroup_deadlock

[Reinhard Tartler]

Control: tag -1 patch

I've filed https://github.com/fatih/semgroup/pull/7 as a workaround.

Anthony, what's your take on this, should we include that patch in the Debian 
Package?

-rt

From bb5f94c0d8e6ddf1f24f673303d73e84c285e1ac Mon Sep 17 00:00:00 2001
From: Reinhard Tartler 
Date: Mon, 13 May 2024 08:31:03 -0400
Subject: [PATCH] chore: bump x/sync to 0.7

Note that this version changes the behavior of semaphore slightly.
After 
https://cs.opensource.google/go/x/sync/+/14be23e5b48bec28285f8a694875175ecacfddb3
the semaphore package will reliably raise errors for both go routines

change the test to test for a substring to be more relaxed in case that
behavior gets reverted
---
 go.mod   | 2 +-
 go.sum   | 4 ++--
 semgroup_test.go | 8 
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/go.mod b/go.mod
index 1a651d6..5926c6b 100644
--- a/go.mod
+++ b/go.mod
@@ -2,4 +2,4 @@ module github.com/fatih/semgroup
 
 go 1.17
 
-require golang.org/x/sync v0.0.0-20210220032951-036812b2e83c

+require golang.org/x/sync v0.7.0
diff --git a/go.sum b/go.sum
index 5c00efd..e8ef4a3 100644
--- a/go.sum
+++ b/go.sum
@@ -1,2 +1,2 @@
-golang.org/x/sync v0.0.0-20210220032951-036812b2e83c 
h1:5KslGYwFpkhGh+Q16bwMP3cOontH8FOep7tGV86Y7SQ=
-golang.org/x/sync v0.0.0-20210220032951-036812b2e83c/go.mod 
h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM=
+golang.org/x/sync v0.7.0 h1:YsImfSBoP9QPYL0xyKJPq0gcaJdG3rInoqxTWbfQu9M=
+golang.org/x/sync v0.7.0/go.mod h1:Czt+wKu1gCyEFDUtn0jG5QVvpJ6rzVqr5aXyt9drQfk=
diff --git a/semgroup_test.go b/semgroup_test.go
index 255206d..3c90bf6 100644
--- a/semgroup_test.go
+++ b/semgroup_test.go
@@ -4,6 +4,7 @@ import (
"context"
"errors"
"os"
+   "strings"
"sync"
"testing"
 )
@@ -85,11 +86,10 @@ func TestGroup_deadlock(t *testing.T) {
t.Fatalf("g.Wait() should return an error")
}
 
-	wantErr := `1 error(s) occurred:

-* couldn't acquire semaphore: context canceled`
+   wantErr := `couldn't acquire semaphore: context canceled`
 
-	if wantErr != err.Error() {

-   t.Errorf("error should be:\n%s\ngot:\n%s\n", wantErr, 
err.Error())
+   if !strings.Contains(err.Error(), wantErr) {
+   t.Errorf("error should contain:\n%s\ngot:\n%s\n", wantErr, 
err.Error())
}
 }
 

Bug#1071038: golang-google-api: timeout in test TestBundlerTimeBasedFlushDeadlock

[Reinhard Tartler]

Source: golang-google-api
Version: 0.61.0-4
Severity: serious
Justification: FTBFS

I am unable to build the package (reliably) on my laptop. It turns out that the
test TestBundlerTimeBasedFlushDeadlock times out after 10 minutes:


It seems that the test introduced by 6114940 is hanging/deadlocking for me:

bundler_test.go:402: timed out: context canceled
panic: test timed out after 10m0s
running tests:
TestBundlerTimeBasedFlushDeadlock (9m57s)

goroutine 1205 [running]:
testing.(*M).startAlarm.func1()
/usr/lib/go-1.22/src/testing/testing.go:2366 +0x385
created by time.goFunc
/usr/lib/go-1.22/src/time/sleep.go:177 +0x2d

goroutine 1 [chan receive, 9 minutes]:
testing.(*T).Run(0xcd6340, {0x556943?, 0x0?}, 0x55bf28)
/usr/lib/go-1.22/src/testing/testing.go:1750 +0x3ab
testing.runTests.func1(0xcd6340)
/usr/lib/go-1.22/src/testing/testing.go:2161 +0x37
testing.tRunner(0xcd6340, 0xca6c70)
/usr/lib/go-1.22/src/testing/testing.go:1689 +0xfb
testing.runTests(0xcaa0a8, {0x65bdc0, 0xd, 0xd}, {0x1?, 0x4b8aae?, 
0x6605a0?})
/usr/lib/go-1.22/src/testing/testing.go:2159 +0x445
testing.(*M).Run(0xcb00a0)
/usr/lib/go-1.22/src/testing/testing.go:2027 +0x68b
main.main()
_testmain.go:79 +0x16c

goroutine 7 [semacquire, 9 minutes]:
sync.runtime_Semacquire(0xc0004aff08?)
/usr/lib/go-1.22/src/runtime/sema.go:62 +0x25
sync.(*WaitGroup).Wait(0x5856c8?)
/usr/lib/go-1.22/src/sync/waitgroup.go:116 +0x48
google.golang.org/api/support/bundler.TestBundlerTimeBasedFlushDeadlock(0xc000304000)

/tmp/autopkgtest.pxElVg/build.3uJ/src/obj-x86_64-linux-gnu/src/google.golang.org/api/support/bundler/bundler_test.go:413
 +0x1b2
testing.tRunner(0xc000304000, 0x55bf28)
/usr/lib/go-1.22/src/testing/testing.go:1689 +0xfb
created by testing.(*T).Run in goroutine 1
/usr/lib/go-1.22/src/testing/testing.go:1742 +0x390

goroutine 54 [select (no cases), 9 minutes]:
google.golang.org/api/support/bundler.TestBundlerErrors.func1({0x522040?, 
0xc0001840d8?})

/tmp/autopkgtest.pxElVg/build.3uJ/src/obj-x86_64-linux-gnu/src/google.golang.org/api/support/bundler/bundler_test.go:245
 +0xf
google.golang.org/api/support/bundler.(*Bundler).handle(0xc0001a20b0, 
0xc00018c0b0?)

/tmp/autopkgtest.pxElVg/build.3uJ/src/obj-x86_64-linux-gnu/src/google.golang.org/api/support/bundler/bundler.go:324
 +0x44
created by google.golang.org/api/support/bundler.(*Bundler).enqueueCurBundle in 
goroutine 53

/tmp/autopkgtest.pxElVg/build.3uJ/src/obj-x86_64-linux-gnu/src/google.golang.org/api/support/bundler/bundler.go:179
 +0x148

goroutine 78 [chan receive, 9 minutes]:
google.golang.org/api/support/bundler.TestAddWait.func2({0x522040?, 
0xc000184018?})

/tmp/autopkgtest.pxElVg/build.3uJ/src/obj-x86_64-linux-gnu/src/google.golang.org/api/support/bundler/bundler_test.go:198
 +0x25
google.golang.org/api/support/bundler.(*Bundler).handle(0xc0001320b0, 0x1af?)

/tmp/autopkgtest.pxElVg/build.3uJ/src/obj-x86_64-linux-gnu/src/google.golang.org/api/support/bundler/bundler.go:324
 +0x44
created by google.golang.org/api/support/bundler.(*Bundler).enqueueCurBundle in 
goroutine 77

/tmp/autopkgtest.pxElVg/build.3uJ/src/obj-x86_64-linux-gnu/src/google.golang.org/api/support/bundler/bundler.go:179
 +0x148
FAILgoogle.golang.org/api/support/bundler   600.035s
testing: warning: no tests to run


This is also experienced on ci.debian.org on:
 - amd64: 
https://ci.debian.net/packages/g/golang-google-api/testing/amd64/46591924/
 - ppc6el: 
https://ci.debian.net/packages/g/golang-google-api/testing/ppc64el/46587668/


This test was introduced here: 
https://github.com/googleapis/google-api-go-client/issues/417

Anthony, Shengjing, what's your thought about simply disabling this test for 
now?

-rt

Bug#1071038: golang-google-api: timeout in test TestBundlerTimeBasedFlushDeadlock

[Reinhard Tartler]

Source: golang-google-api
Version: 0.61.0-4
Severity: serious
Justification: FTBFS

I am unable to build the package (reliably) on my laptop. It turns out that the
test TestBundlerTimeBasedFlushDeadlock times out after 10 minutes:


It seems that the test introduced by 6114940 is hanging/deadlocking for me:

bundler_test.go:402: timed out: context canceled
panic: test timed out after 10m0s
running tests:
TestBundlerTimeBasedFlushDeadlock (9m57s)

goroutine 1205 [running]:
testing.(*M).startAlarm.func1()
/usr/lib/go-1.22/src/testing/testing.go:2366 +0x385
created by time.goFunc
/usr/lib/go-1.22/src/time/sleep.go:177 +0x2d

goroutine 1 [chan receive, 9 minutes]:
testing.(*T).Run(0xcd6340, {0x556943?, 0x0?}, 0x55bf28)
/usr/lib/go-1.22/src/testing/testing.go:1750 +0x3ab
testing.runTests.func1(0xcd6340)
/usr/lib/go-1.22/src/testing/testing.go:2161 +0x37
testing.tRunner(0xcd6340, 0xca6c70)
/usr/lib/go-1.22/src/testing/testing.go:1689 +0xfb
testing.runTests(0xcaa0a8, {0x65bdc0, 0xd, 0xd}, {0x1?, 0x4b8aae?, 
0x6605a0?})
/usr/lib/go-1.22/src/testing/testing.go:2159 +0x445
testing.(*M).Run(0xcb00a0)
/usr/lib/go-1.22/src/testing/testing.go:2027 +0x68b
main.main()
_testmain.go:79 +0x16c

goroutine 7 [semacquire, 9 minutes]:
sync.runtime_Semacquire(0xc0004aff08?)
/usr/lib/go-1.22/src/runtime/sema.go:62 +0x25
sync.(*WaitGroup).Wait(0x5856c8?)
/usr/lib/go-1.22/src/sync/waitgroup.go:116 +0x48
google.golang.org/api/support/bundler.TestBundlerTimeBasedFlushDeadlock(0xc000304000)

/tmp/autopkgtest.pxElVg/build.3uJ/src/obj-x86_64-linux-gnu/src/google.golang.org/api/support/bundler/bundler_test.go:413
 +0x1b2
testing.tRunner(0xc000304000, 0x55bf28)
/usr/lib/go-1.22/src/testing/testing.go:1689 +0xfb
created by testing.(*T).Run in goroutine 1
/usr/lib/go-1.22/src/testing/testing.go:1742 +0x390

goroutine 54 [select (no cases), 9 minutes]:
google.golang.org/api/support/bundler.TestBundlerErrors.func1({0x522040?, 
0xc0001840d8?})

/tmp/autopkgtest.pxElVg/build.3uJ/src/obj-x86_64-linux-gnu/src/google.golang.org/api/support/bundler/bundler_test.go:245
 +0xf
google.golang.org/api/support/bundler.(*Bundler).handle(0xc0001a20b0, 
0xc00018c0b0?)

/tmp/autopkgtest.pxElVg/build.3uJ/src/obj-x86_64-linux-gnu/src/google.golang.org/api/support/bundler/bundler.go:324
 +0x44
created by google.golang.org/api/support/bundler.(*Bundler).enqueueCurBundle in 
goroutine 53

/tmp/autopkgtest.pxElVg/build.3uJ/src/obj-x86_64-linux-gnu/src/google.golang.org/api/support/bundler/bundler.go:179
 +0x148

goroutine 78 [chan receive, 9 minutes]:
google.golang.org/api/support/bundler.TestAddWait.func2({0x522040?, 
0xc000184018?})

/tmp/autopkgtest.pxElVg/build.3uJ/src/obj-x86_64-linux-gnu/src/google.golang.org/api/support/bundler/bundler_test.go:198
 +0x25
google.golang.org/api/support/bundler.(*Bundler).handle(0xc0001320b0, 0x1af?)

/tmp/autopkgtest.pxElVg/build.3uJ/src/obj-x86_64-linux-gnu/src/google.golang.org/api/support/bundler/bundler.go:324
 +0x44
created by google.golang.org/api/support/bundler.(*Bundler).enqueueCurBundle in 
goroutine 77

/tmp/autopkgtest.pxElVg/build.3uJ/src/obj-x86_64-linux-gnu/src/google.golang.org/api/support/bundler/bundler.go:179
 +0x148
FAILgoogle.golang.org/api/support/bundler   600.035s
testing: warning: no tests to run


This is also experienced on ci.debian.org on:
 - amd64: 
https://ci.debian.net/packages/g/golang-google-api/testing/amd64/46591924/
 - ppc6el: 
https://ci.debian.net/packages/g/golang-google-api/testing/ppc64el/46587668/


This test was introduced here: 
https://github.com/googleapis/google-api-go-client/issues/417

Anthony, Shengjing, what's your thought about simply disabling this test for 
now?

-rt

Bug#1071035: FAIL: TestGroup_deadlock

[Reinhard Tartler]

Source: golang-github-fatih-semgroup
Version: 1.2.0-2
Severity: serious
Justification: FTBFS

Your package fails to build from source, more specifically, when running the
test suite. I can reproduce on my amd64 laptop. Here is the relevant part of 
the log:

   dh_auto_test -O--builddirectory=_build -O--buildsystem=golang
cd _build && go test -vet=off -v -p 8 github.com/fatih/semgroup
=== RUN   TestGroup_single_task
--- PASS: TestGroup_single_task (0.00s)
=== RUN   TestGroup_multiple_tasks
--- PASS: TestGroup_multiple_tasks (0.00s)
=== RUN   TestGroup_multiple_tasks_errors
--- PASS: TestGroup_multiple_tasks_errors (0.00s)
=== RUN   TestGroup_deadlock
semgroup_test.go:92: error should be:
1 error(s) occurred:
* couldn't acquire semaphore: context canceled
got:
2 error(s) occurred:
* couldn't acquire semaphore: context canceled
* couldn't acquire semaphore: context canceled
--- FAIL: TestGroup_deadlock (0.00s)
=== RUN   TestGroup_multiple_tasks_errors_Is
--- PASS: TestGroup_multiple_tasks_errors_Is (0.00s)
=== RUN   TestGroup_multiple_tasks_errors_As
--- PASS: TestGroup_multiple_tasks_errors_As (0.00s)
=== RUN   ExampleGroup_parallel
--- PASS: ExampleGroup_parallel (0.00s)
=== RUN   ExampleGroup_withErrors
--- PASS: ExampleGroup_withErrors (0.00s)
FAIL
FAILgithub.com/fatih/semgroup   0.002s
FAIL
dh_auto_test: error: cd _build && go test -vet=off -v -p 8 
github.com/fatih/semgroup returned exit code 1




-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.12-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
sbuild (Debian sbuild) 0.85.8 (25 April 2024) on x1.int.tauware.de

+==+
| golang-github-fatih-semgroup 1.2.0-2 (amd64) Mon, 13 May 2024 10:17:26 + |
+==+

Package: golang-github-fatih-semgroup
Version: 1.2.0-2
Source Version: 1.2.0-2
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-amd64-sbuild-c4abcda8-6c4c-46bc-a658-fa5bbda190de'
 with '<>'
I: NOTICE: Log filtering will replace 
'build/golang-github-fatih-semgroup-jAWYkc/resolver-Z2VXYh' with 
'<>'

+--+
| Update chroot|
+--+

Hit:1 http://127.0.0.1:3142/deb.debian.org/debian unstable InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Local sources
-

/tmp/docker.io/golang-github-fatih-semgroup_1.2.0-2.dsc exists in 
/tmp/docker.io; copying to chroot
I: NOTICE: Log filtering will replace 
'build/golang-github-fatih-semgroup-jAWYkc/golang-github-fatih-semgroup-1.2.0' 
with '<>'
I: NOTICE: Log filtering will replace 
'build/golang-github-fatih-semgroup-jAWYkc' with '<>'

+--+
| Install package build dependencies   |
+--+


Setup apt archive
-

Merged Build-Depends: debhelper-compat (= 13), dh-sequence-golang, golang-any 
(>= 2:1.17~), golang-golang-x-sync-dev, build-essential, fakeroot
Filtered Build-Depends: debhelper-compat (= 13), dh-sequence-golang, golang-any 
(>= 2:1.17~), golang-golang-x-sync-dev, build-essential, fakeroot
dpkg-deb: building package 'sbuild-build-depends-main-dummy' in 
'/<>/apt_archive/sbuild-build-depends-main-dummy.deb'.
Ign:1 copy:/<>/apt_archive ./ InRelease
Get:2 copy:/<>/apt_archive ./ Release [609 B]
Ign:3 copy:/<>/apt_archive ./ Release.gpg
Get:4 copy:/<>/apt_archive ./ Sources [688 B]
Get:5 copy:/<>/apt_archive ./ Packages [720 B]
Fetched 2017 B in 0s (0 B/s)
Reading package lists...
Reading package lists...

Install main build dependencies (apt-based resolver)


Installing build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
The following 

Bug#1071035: FAIL: TestGroup_deadlock

[Reinhard Tartler]

Source: golang-github-fatih-semgroup
Version: 1.2.0-2
Severity: serious
Justification: FTBFS

Your package fails to build from source, more specifically, when running the
test suite. I can reproduce on my amd64 laptop. Here is the relevant part of 
the log:

   dh_auto_test -O--builddirectory=_build -O--buildsystem=golang
cd _build && go test -vet=off -v -p 8 github.com/fatih/semgroup
=== RUN   TestGroup_single_task
--- PASS: TestGroup_single_task (0.00s)
=== RUN   TestGroup_multiple_tasks
--- PASS: TestGroup_multiple_tasks (0.00s)
=== RUN   TestGroup_multiple_tasks_errors
--- PASS: TestGroup_multiple_tasks_errors (0.00s)
=== RUN   TestGroup_deadlock
semgroup_test.go:92: error should be:
1 error(s) occurred:
* couldn't acquire semaphore: context canceled
got:
2 error(s) occurred:
* couldn't acquire semaphore: context canceled
* couldn't acquire semaphore: context canceled
--- FAIL: TestGroup_deadlock (0.00s)
=== RUN   TestGroup_multiple_tasks_errors_Is
--- PASS: TestGroup_multiple_tasks_errors_Is (0.00s)
=== RUN   TestGroup_multiple_tasks_errors_As
--- PASS: TestGroup_multiple_tasks_errors_As (0.00s)
=== RUN   ExampleGroup_parallel
--- PASS: ExampleGroup_parallel (0.00s)
=== RUN   ExampleGroup_withErrors
--- PASS: ExampleGroup_withErrors (0.00s)
FAIL
FAILgithub.com/fatih/semgroup   0.002s
FAIL
dh_auto_test: error: cd _build && go test -vet=off -v -p 8 
github.com/fatih/semgroup returned exit code 1




-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.12-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
sbuild (Debian sbuild) 0.85.8 (25 April 2024) on x1.int.tauware.de

+==+
| golang-github-fatih-semgroup 1.2.0-2 (amd64) Mon, 13 May 2024 10:17:26 + |
+==+

Package: golang-github-fatih-semgroup
Version: 1.2.0-2
Source Version: 1.2.0-2
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-amd64-sbuild-c4abcda8-6c4c-46bc-a658-fa5bbda190de'
 with '<>'
I: NOTICE: Log filtering will replace 
'build/golang-github-fatih-semgroup-jAWYkc/resolver-Z2VXYh' with 
'<>'

+--+
| Update chroot|
+--+

Hit:1 http://127.0.0.1:3142/deb.debian.org/debian unstable InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Local sources
-

/tmp/docker.io/golang-github-fatih-semgroup_1.2.0-2.dsc exists in 
/tmp/docker.io; copying to chroot
I: NOTICE: Log filtering will replace 
'build/golang-github-fatih-semgroup-jAWYkc/golang-github-fatih-semgroup-1.2.0' 
with '<>'
I: NOTICE: Log filtering will replace 
'build/golang-github-fatih-semgroup-jAWYkc' with '<>'

+--+
| Install package build dependencies   |
+--+


Setup apt archive
-

Merged Build-Depends: debhelper-compat (= 13), dh-sequence-golang, golang-any 
(>= 2:1.17~), golang-golang-x-sync-dev, build-essential, fakeroot
Filtered Build-Depends: debhelper-compat (= 13), dh-sequence-golang, golang-any 
(>= 2:1.17~), golang-golang-x-sync-dev, build-essential, fakeroot
dpkg-deb: building package 'sbuild-build-depends-main-dummy' in 
'/<>/apt_archive/sbuild-build-depends-main-dummy.deb'.
Ign:1 copy:/<>/apt_archive ./ InRelease
Get:2 copy:/<>/apt_archive ./ Release [609 B]
Ign:3 copy:/<>/apt_archive ./ Release.gpg
Get:4 copy:/<>/apt_archive ./ Sources [688 B]
Get:5 copy:/<>/apt_archive ./ Packages [720 B]
Fetched 2017 B in 0s (0 B/s)
Reading package lists...
Reading package lists...

Install main build dependencies (apt-based resolver)


Installing build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
The following 

Bug#1070821: Turns out to be flaky tests

[Reinhard Tartler]

Control: Severity -1 important
Control: Retitle -1 testsuite is flaky

Looking at the build failures, there appears to be at least two tests that
are flaky.

One being in daemon/logger:
https://sources.debian.org/src/docker.io/20.10.25%2Bdfsg1-3/engine/daemon/logger/copier_test.go/#L261-L265

The other one manifesting as a segfault:

=== FAIL: daemon TestExecSetPlatformOpt (0.00s)
panic: runtime error: invalid memory address or nil pointer
dereference [recovered]
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x2424ce6]

goroutine 101 [running]:
testing.tRunner.func1.2({0x26d8820, 0x4032710})
/usr/lib/go-1.22/src/testing/testing.go:1631 +0x24a
testing.tRunner.func1()
/usr/lib/go-1.22/src/testing/testing.go:1634 +0x377
panic({0x26d8820?, 0x4032710?})
/usr/lib/go-1.22/src/runtime/panic.go:770
+0x132github.com/docker/docker/daemon.(*Daemon).execSetPlatformOpt.WithRlimits.func1({0x30820c0?,
0x413aba0?}, {0x0?, 0x0?}, 0x0?, 0xc000a49810)

/<>/_build/src/github.com/docker/docker/daemon/oci_linux.go:46
+0x46github.com/docker/docker/daemon.(*Daemon).execSetPlatformOpt(0xc000aa1d88,
0xc000aa1b40, 0xc000aa1998?, 0xc000aa1970)

/<>/_build/src/github.com/docker/docker/daemon/exec_linux.go:54
+0x503github.com/docker/docker/daemon.TestExecSetPlatformOpt(0xc000a77a00)

/<>/_build/src/github.com/docker/docker/daemon/exec_linux_test.go:26
+0x155
testing.tRunner(0xc000a77a00, 0x2aaeba0)
/usr/lib/go-1.22/src/testing/testing.go:1689 +0xfb
created by testing.(*T).Run in goroutine 1
/usr/lib/go-1.22/src/testing/testing.go:1742 +0x390


Source code here:
https://sources.debian.org/src/docker.io/20.10.25%2Bdfsg1-3/engine/daemon/oci_linux.go/#L46


not sure what makes them trigger.  Maybe machines got faster and it is
easier to trigger these issues? Not sure how to go about this, besides
removing the two tests in question.


-- 
regards,
Reinhard

Bug#1070821: Turns out to be flaky tests

[Reinhard Tartler]

Control: Severity -1 important
Control: Retitle -1 testsuite is flaky

Looking at the build failures, there appears to be at least two tests that
are flaky.

One being in daemon/logger:
https://sources.debian.org/src/docker.io/20.10.25%2Bdfsg1-3/engine/daemon/logger/copier_test.go/#L261-L265

The other one manifesting as a segfault:

=== FAIL: daemon TestExecSetPlatformOpt (0.00s)
panic: runtime error: invalid memory address or nil pointer
dereference [recovered]
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x2424ce6]

goroutine 101 [running]:
testing.tRunner.func1.2({0x26d8820, 0x4032710})
/usr/lib/go-1.22/src/testing/testing.go:1631 +0x24a
testing.tRunner.func1()
/usr/lib/go-1.22/src/testing/testing.go:1634 +0x377
panic({0x26d8820?, 0x4032710?})
/usr/lib/go-1.22/src/runtime/panic.go:770
+0x132github.com/docker/docker/daemon.(*Daemon).execSetPlatformOpt.WithRlimits.func1({0x30820c0?,
0x413aba0?}, {0x0?, 0x0?}, 0x0?, 0xc000a49810)

/<>/_build/src/github.com/docker/docker/daemon/oci_linux.go:46
+0x46github.com/docker/docker/daemon.(*Daemon).execSetPlatformOpt(0xc000aa1d88,
0xc000aa1b40, 0xc000aa1998?, 0xc000aa1970)

/<>/_build/src/github.com/docker/docker/daemon/exec_linux.go:54
+0x503github.com/docker/docker/daemon.TestExecSetPlatformOpt(0xc000a77a00)

/<>/_build/src/github.com/docker/docker/daemon/exec_linux_test.go:26
+0x155
testing.tRunner(0xc000a77a00, 0x2aaeba0)
/usr/lib/go-1.22/src/testing/testing.go:1689 +0xfb
created by testing.(*T).Run in goroutine 1
/usr/lib/go-1.22/src/testing/testing.go:1742 +0x390


Source code here:
https://sources.debian.org/src/docker.io/20.10.25%2Bdfsg1-3/engine/daemon/oci_linux.go/#L46


not sure what makes them trigger.  Maybe machines got faster and it is
easier to trigger these issues? Not sure how to go about this, besides
removing the two tests in question.


-- 
regards,
Reinhard

Bug#1070727: reportbug: podman does not run wasm/wasi images because of missing crun-wasm - easy fix

[Reinhard Tartler]

Thanks for looking into this,

On Sat, May 11, 2024 at 6:00 AM Faidon Liambotis 
wrote:

> Control: tags -1 confirmed
>
> On Wed, May 08, 2024 at 03:10:40AM +0300, Eugen Stan wrote:
> > I followed the guide to run wasm images on my system and it failed with
> > errors.
> >
> > I believe the issue is that podman looks for crun-wasm binary by default.
> > I failed to configure podman to use crun instead of crun-wasm.
> > I created a simbolic link named crun-wasm:
> >
> > sudo ln -s /usr/bin/crun /usr/local/bin/crun-wasm
>
> Ouch! You're right. This worked when I enabled WasmEdge in crun, but
> was changed upstream at some point since.
>
> Apparently Fedora/RedHat ship a "crun-wasm" package, which contains a) this
> symlink, b) a dependency on WasmEdge.
>
> In Debian, the main "crun" package has a Suggests on libwasmedge0.
>
> I see three paths forward:
> 1) We do the same, creating a new (almost) empty package.
> 2) We ship a /usr/bin/crun-wasm symlink in the crun package.
> 3) We patch podman to use /usr/bin/crun instead of, or in addition to,
> /usr/bin/crun-wasm.
>
> I don't particularly love option (1). I'm split between options (2) and
> (3), not loving either.
>
> Thoughts?
>

I think we should do either 1 or 2 to minimize divergence with upstream. My
preference would be 2 to enable an out-of-the box experience.

Is there any reason to not have that symlink installed by default in the
`crun` package?


-- 
regards,
Reinhard

[pkg-go] Bug#1070727: reportbug: podman does not run wasm/wasi images because of missing crun-wasm - easy fix

[Reinhard Tartler]

Thanks for looking into this,

On Sat, May 11, 2024 at 6:00 AM Faidon Liambotis 
wrote:

> Control: tags -1 confirmed
>
> On Wed, May 08, 2024 at 03:10:40AM +0300, Eugen Stan wrote:
> > I followed the guide to run wasm images on my system and it failed with
> > errors.
> >
> > I believe the issue is that podman looks for crun-wasm binary by default.
> > I failed to configure podman to use crun instead of crun-wasm.
> > I created a simbolic link named crun-wasm:
> >
> > sudo ln -s /usr/bin/crun /usr/local/bin/crun-wasm
>
> Ouch! You're right. This worked when I enabled WasmEdge in crun, but
> was changed upstream at some point since.
>
> Apparently Fedora/RedHat ship a "crun-wasm" package, which contains a) this
> symlink, b) a dependency on WasmEdge.
>
> In Debian, the main "crun" package has a Suggests on libwasmedge0.
>
> I see three paths forward:
> 1) We do the same, creating a new (almost) empty package.
> 2) We ship a /usr/bin/crun-wasm symlink in the crun package.
> 3) We patch podman to use /usr/bin/crun instead of, or in addition to,
> /usr/bin/crun-wasm.
>
> I don't particularly love option (1). I'm split between options (2) and
> (3), not loving either.
>
> Thoughts?
>

I think we should do either 1 or 2 to minimize divergence with upstream. My
preference would be 2 to enable an out-of-the box experience.

Is there any reason to not have that symlink installed by default in the
`crun` package?


-- 
regards,
Reinhard
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Bug#1068755: closing 1068755

[Reinhard Tartler]

close 1068755 20.10.25+dfsg1-3
thanks

docker.io 20.10.25+dfsg1-3 comes with a backported patch that addresses this
FTBFS

Bug#1069310: FTBFS: tests failed

[Reinhard Tartler]

I spent about half an hour looking at this, and wanted to share my thoughts:

- the build / tests succeed on all architectures but mips64el
- the panic in question appears to come from here:
https://sources.debian.org/src/golang-github-hanwen-go-fuse/2.4.2-2/fuse/print_linux.go/#L13
--
a map[int64]string is being set with the key "syscall.O_DIRECT" to the
value "DIRECT".
- that map is pre-initialized here:
https://sources.debian.org/src/golang-github-hanwen-go-fuse/2.4.2-2/fuse/print.go/#L64-L80
- on most architectures, such as amd64, the constant `syscall.O_DIRECT` is
set to the value 0x4000, cf.
https://cs.opensource.google/go/go/+/master:src/syscall/zerrors_linux_amd64.go;l=627;bpv=0;bpt=1
- on mipsel64, the value is set to 0x8000, cf.
https://cs.opensource.google/go/go/+/master:src/syscall/zerrors_linux_mips64.go;l=774?q=O_DIRECT=go%2Fgo=11
- this value conflicts with
https://sources.debian.org/src/golang-github-hanwen-go-fuse/2.4.2-2/fuse/print.go/#L77
so
we now get conflicting values for the same key. This explains the message
"panic: DIRECT (8000) overlaps with LARGEFILE (8000).

-- 
regards,
Reinhard

Bug#1069310: FTBFS: tests failed

[Reinhard Tartler]

I spent about half an hour looking at this, and wanted to share my thoughts:

- the build / tests succeed on all architectures but mips64el
- the panic in question appears to come from here:
https://sources.debian.org/src/golang-github-hanwen-go-fuse/2.4.2-2/fuse/print_linux.go/#L13
--
a map[int64]string is being set with the key "syscall.O_DIRECT" to the
value "DIRECT".
- that map is pre-initialized here:
https://sources.debian.org/src/golang-github-hanwen-go-fuse/2.4.2-2/fuse/print.go/#L64-L80
- on most architectures, such as amd64, the constant `syscall.O_DIRECT` is
set to the value 0x4000, cf.
https://cs.opensource.google/go/go/+/master:src/syscall/zerrors_linux_amd64.go;l=627;bpv=0;bpt=1
- on mipsel64, the value is set to 0x8000, cf.
https://cs.opensource.google/go/go/+/master:src/syscall/zerrors_linux_mips64.go;l=774?q=O_DIRECT=go%2Fgo=11
- this value conflicts with
https://sources.debian.org/src/golang-github-hanwen-go-fuse/2.4.2-2/fuse/print.go/#L77
so
we now get conflicting values for the same key. This explains the message
"panic: DIRECT (8000) overlaps with LARGEFILE (8000).

-- 
regards,
Reinhard

Bug#1068755: FTBFS: tests failed

[Reinhard Tartler]

please ignore the above, it was meant to be sent to #1069310 instead

On Mon, May 6, 2024 at 6:34 AM Reinhard Tartler  wrote:

> I spent about half an hour looking at this, and wanted to share my
> thoughts:
>
> - the build / tests succeed on all architectures but mips64el
> - the panic in question appears to come from here:
> https://sources.debian.org/src/golang-github-hanwen-go-fuse/2.4.2-2/fuse/print_linux.go/#L13
> -- a map[int64]string is being set with the key "syscall.O_DIRECT" to the
> value "DIRECT".
> - that map is pre-initialized here:
> https://sources.debian.org/src/golang-github-hanwen-go-fuse/2.4.2-2/fuse/print.go/#L64-L80
> - on most architectures, such as amd64, the constant `syscall.O_DIRECT` is
> set to the value 0x4000, cf.
> https://cs.opensource.google/go/go/+/master:src/syscall/zerrors_linux_amd64.go;l=627;bpv=0;bpt=1
> - on mipsel64, the value is set to 0x8000, cf.
> https://cs.opensource.google/go/go/+/master:src/syscall/zerrors_linux_mips64.go;l=774?q=O_DIRECT=go%2Fgo=11
> - this value conflicts with
> https://sources.debian.org/src/golang-github-hanwen-go-fuse/2.4.2-2/fuse/print.go/#L77
> so we now get conflicting values for the same key. This explains the
> message "panic: DIRECT (8000) overlaps with LARGEFILE (8000).
>
>
> --
> regards,
> Reinhard
>


-- 
regards,
Reinhard

Bug#1068755: FTBFS: tests failed

[Reinhard Tartler]

please ignore the above, it was meant to be sent to #1069310 instead

On Mon, May 6, 2024 at 6:34 AM Reinhard Tartler  wrote:

> I spent about half an hour looking at this, and wanted to share my
> thoughts:
>
> - the build / tests succeed on all architectures but mips64el
> - the panic in question appears to come from here:
> https://sources.debian.org/src/golang-github-hanwen-go-fuse/2.4.2-2/fuse/print_linux.go/#L13
> -- a map[int64]string is being set with the key "syscall.O_DIRECT" to the
> value "DIRECT".
> - that map is pre-initialized here:
> https://sources.debian.org/src/golang-github-hanwen-go-fuse/2.4.2-2/fuse/print.go/#L64-L80
> - on most architectures, such as amd64, the constant `syscall.O_DIRECT` is
> set to the value 0x4000, cf.
> https://cs.opensource.google/go/go/+/master:src/syscall/zerrors_linux_amd64.go;l=627;bpv=0;bpt=1
> - on mipsel64, the value is set to 0x8000, cf.
> https://cs.opensource.google/go/go/+/master:src/syscall/zerrors_linux_mips64.go;l=774?q=O_DIRECT=go%2Fgo=11
> - this value conflicts with
> https://sources.debian.org/src/golang-github-hanwen-go-fuse/2.4.2-2/fuse/print.go/#L77
> so we now get conflicting values for the same key. This explains the
> message "panic: DIRECT (8000) overlaps with LARGEFILE (8000).
>
>
> --
> regards,
> Reinhard
>


-- 
regards,
Reinhard

Bug#1068755: FTBFS: tests failed

[Reinhard Tartler]

I spent about half an hour looking at this, and wanted to share my thoughts:

- the build / tests succeed on all architectures but mips64el
- the panic in question appears to come from here:
https://sources.debian.org/src/golang-github-hanwen-go-fuse/2.4.2-2/fuse/print_linux.go/#L13
-- a map[int64]string is being set with the key "syscall.O_DIRECT" to the
value "DIRECT".
- that map is pre-initialized here:
https://sources.debian.org/src/golang-github-hanwen-go-fuse/2.4.2-2/fuse/print.go/#L64-L80
- on most architectures, such as amd64, the constant `syscall.O_DIRECT` is
set to the value 0x4000, cf.
https://cs.opensource.google/go/go/+/master:src/syscall/zerrors_linux_amd64.go;l=627;bpv=0;bpt=1
- on mipsel64, the value is set to 0x8000, cf.
https://cs.opensource.google/go/go/+/master:src/syscall/zerrors_linux_mips64.go;l=774?q=O_DIRECT=go%2Fgo=11
- this value conflicts with
https://sources.debian.org/src/golang-github-hanwen-go-fuse/2.4.2-2/fuse/print.go/#L77
so we now get conflicting values for the same key. This explains the
message "panic: DIRECT (8000) overlaps with LARGEFILE (8000).


-- 
regards,
Reinhard

[pkg-go] Bug#1069310: FTBFS: tests failed

[Reinhard Tartler]

I spent about half an hour looking at this, and wanted to share my thoughts:

- the build / tests succeed on all architectures but mips64el
- the panic in question appears to come from here:
https://sources.debian.org/src/golang-github-hanwen-go-fuse/2.4.2-2/fuse/print_linux.go/#L13
--
a map[int64]string is being set with the key "syscall.O_DIRECT" to the
value "DIRECT".
- that map is pre-initialized here:
https://sources.debian.org/src/golang-github-hanwen-go-fuse/2.4.2-2/fuse/print.go/#L64-L80
- on most architectures, such as amd64, the constant `syscall.O_DIRECT` is
set to the value 0x4000, cf.
https://cs.opensource.google/go/go/+/master:src/syscall/zerrors_linux_amd64.go;l=627;bpv=0;bpt=1
- on mipsel64, the value is set to 0x8000, cf.
https://cs.opensource.google/go/go/+/master:src/syscall/zerrors_linux_mips64.go;l=774?q=O_DIRECT=go%2Fgo=11
- this value conflicts with
https://sources.debian.org/src/golang-github-hanwen-go-fuse/2.4.2-2/fuse/print.go/#L77
so
we now get conflicting values for the same key. This explains the message
"panic: DIRECT (8000) overlaps with LARGEFILE (8000).

-- 
regards,
Reinhard
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Bug#1068755: FTBFS: tests failed

[Reinhard Tartler]

I spent about half an hour looking at this, and wanted to share my thoughts:

- the build / tests succeed on all architectures but mips64el
- the panic in question appears to come from here:
https://sources.debian.org/src/golang-github-hanwen-go-fuse/2.4.2-2/fuse/print_linux.go/#L13
-- a map[int64]string is being set with the key "syscall.O_DIRECT" to the
value "DIRECT".
- that map is pre-initialized here:
https://sources.debian.org/src/golang-github-hanwen-go-fuse/2.4.2-2/fuse/print.go/#L64-L80
- on most architectures, such as amd64, the constant `syscall.O_DIRECT` is
set to the value 0x4000, cf.
https://cs.opensource.google/go/go/+/master:src/syscall/zerrors_linux_amd64.go;l=627;bpv=0;bpt=1
- on mipsel64, the value is set to 0x8000, cf.
https://cs.opensource.google/go/go/+/master:src/syscall/zerrors_linux_mips64.go;l=774?q=O_DIRECT=go%2Fgo=11
- this value conflicts with
https://sources.debian.org/src/golang-github-hanwen-go-fuse/2.4.2-2/fuse/print.go/#L77
so we now get conflicting values for the same key. This explains the
message "panic: DIRECT (8000) overlaps with LARGEFILE (8000).


-- 
regards,
Reinhard

Bug#1068755: docker.io: FTBFS: failing tests

[Reinhard Tartler]

Turns out that backporting
https://github.com/moby/moby/commit/97921915a801dd82b1f5a70e0a69353539c1e3ae.patch
seems to actually make the test pass

I'm not sure why that worked before, but I've pushed a backport of that
patch to
https://salsa.debian.org/go-team/packages/docker/-/commit/d33659365984dbb47b6aac2836727e507c1ce737
to let the salsa pipeline work on it.

I plan to make a team-upload tomorrow or later in the week. Please let me
know if you have concerns or thoughts on this.

Thanks
-rt

On Sun, May 5, 2024 at 11:20 AM Reinhard Tartler  wrote:

> I've been looking at this test failure, but remain puzzled.
>
> Basically, the source for this test is here:
> https://sources.debian.org/src/docker.io/20.10.25%2Bdfsg1-2/engine/distribution/xfer/download_test.go/#L364-L429.
> This test is testing code in
> https://sources.debian.org/src/docker.io/20.10.25+dfsg1-2/engine/distribution/xfer/download.go
> which has only two external dependencies
> (golang-github-docker-distribution-dev) and
> (golang-github-sirupsen-logrus-dev).
>
> I've checked the build log of the previous build at
> https://buildd.debian.org/status/fetch.php?pkg=docker.io=amd64=20.10.25%2Bdfsg1-2%2Bb3=1704672923=0
> and note that the same test passes in that build. This also uses the same
> package versions of golang-github-docker-distribution-dev==2.8.2+ds1-1 and
> golang-github-sirupsen-logrus-dev==1.9.0-1
>
> I also note that the old build was using golang 1.21, and the FTBFS was
> introduced after upgrading unstable to golang 1.22.
>
> Shengjing, I believe you handled the recent update of the golang toolchain
> from 1.21 to 1.22. Have you seen similar "mysterious" test failures that
> resulted from using a newer golang compiler?
>
> I am considering just disabling this test, as the rest of the testsuite
> seem to pass, but I'm getting nervous that this wouldn't just paper over a
> real issue.
>
> Thanks,
>
>
> --
> regards,
> Reinhard
>


-- 
regards,
Reinhard

Bug#1068755: docker.io: FTBFS: failing tests

[Reinhard Tartler]

Turns out that backporting
https://github.com/moby/moby/commit/97921915a801dd82b1f5a70e0a69353539c1e3ae.patch
seems to actually make the test pass

I'm not sure why that worked before, but I've pushed a backport of that
patch to
https://salsa.debian.org/go-team/packages/docker/-/commit/d33659365984dbb47b6aac2836727e507c1ce737
to let the salsa pipeline work on it.

I plan to make a team-upload tomorrow or later in the week. Please let me
know if you have concerns or thoughts on this.

Thanks
-rt

On Sun, May 5, 2024 at 11:20 AM Reinhard Tartler  wrote:

> I've been looking at this test failure, but remain puzzled.
>
> Basically, the source for this test is here:
> https://sources.debian.org/src/docker.io/20.10.25%2Bdfsg1-2/engine/distribution/xfer/download_test.go/#L364-L429.
> This test is testing code in
> https://sources.debian.org/src/docker.io/20.10.25+dfsg1-2/engine/distribution/xfer/download.go
> which has only two external dependencies
> (golang-github-docker-distribution-dev) and
> (golang-github-sirupsen-logrus-dev).
>
> I've checked the build log of the previous build at
> https://buildd.debian.org/status/fetch.php?pkg=docker.io=amd64=20.10.25%2Bdfsg1-2%2Bb3=1704672923=0
> and note that the same test passes in that build. This also uses the same
> package versions of golang-github-docker-distribution-dev==2.8.2+ds1-1 and
> golang-github-sirupsen-logrus-dev==1.9.0-1
>
> I also note that the old build was using golang 1.21, and the FTBFS was
> introduced after upgrading unstable to golang 1.22.
>
> Shengjing, I believe you handled the recent update of the golang toolchain
> from 1.21 to 1.22. Have you seen similar "mysterious" test failures that
> resulted from using a newer golang compiler?
>
> I am considering just disabling this test, as the rest of the testsuite
> seem to pass, but I'm getting nervous that this wouldn't just paper over a
> real issue.
>
> Thanks,
>
>
> --
> regards,
> Reinhard
>


-- 
regards,
Reinhard

Bug#1068755: marked as pending in docker.io

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #1068755 in docker.io reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/go-team/packages/docker/-/commit/d33659365984dbb47b6aac2836727e507c1ce737


fix test TestMaxDownloadAttempts, closes: #1068755


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1068755

Bug#1068755: docker.io: FTBFS: failing tests

[Reinhard Tartler]

I've been looking at this test failure, but remain puzzled.

Basically, the source for this test is here:
https://sources.debian.org/src/docker.io/20.10.25%2Bdfsg1-2/engine/distribution/xfer/download_test.go/#L364-L429.
This test is testing code in
https://sources.debian.org/src/docker.io/20.10.25+dfsg1-2/engine/distribution/xfer/download.go
which has only two external dependencies
(golang-github-docker-distribution-dev) and
(golang-github-sirupsen-logrus-dev).

I've checked the build log of the previous build at
https://buildd.debian.org/status/fetch.php?pkg=docker.io=amd64=20.10.25%2Bdfsg1-2%2Bb3=1704672923=0
and note that the same test passes in that build. This also uses the same
package versions of golang-github-docker-distribution-dev==2.8.2+ds1-1 and
golang-github-sirupsen-logrus-dev==1.9.0-1

I also note that the old build was using golang 1.21, and the FTBFS was
introduced after upgrading unstable to golang 1.22.

Shengjing, I believe you handled the recent update of the golang toolchain
from 1.21 to 1.22. Have you seen similar "mysterious" test failures that
resulted from using a newer golang compiler?

I am considering just disabling this test, as the rest of the testsuite
seem to pass, but I'm getting nervous that this wouldn't just paper over a
real issue.

Thanks,


-- 
regards,
Reinhard

Bug#1068755: docker.io: FTBFS: failing tests

[Reinhard Tartler]

I've been looking at this test failure, but remain puzzled.

Basically, the source for this test is here:
https://sources.debian.org/src/docker.io/20.10.25%2Bdfsg1-2/engine/distribution/xfer/download_test.go/#L364-L429.
This test is testing code in
https://sources.debian.org/src/docker.io/20.10.25+dfsg1-2/engine/distribution/xfer/download.go
which has only two external dependencies
(golang-github-docker-distribution-dev) and
(golang-github-sirupsen-logrus-dev).

I've checked the build log of the previous build at
https://buildd.debian.org/status/fetch.php?pkg=docker.io=amd64=20.10.25%2Bdfsg1-2%2Bb3=1704672923=0
and note that the same test passes in that build. This also uses the same
package versions of golang-github-docker-distribution-dev==2.8.2+ds1-1 and
golang-github-sirupsen-logrus-dev==1.9.0-1

I also note that the old build was using golang 1.21, and the FTBFS was
introduced after upgrading unstable to golang 1.22.

Shengjing, I believe you handled the recent update of the golang toolchain
from 1.21 to 1.22. Have you seen similar "mysterious" test failures that
resulted from using a newer golang compiler?

I am considering just disabling this test, as the rest of the testsuite
seem to pass, but I'm getting nervous that this wouldn't just paper over a
real issue.

Thanks,


-- 
regards,
Reinhard

Re: docker.io: FTBFS: failing tests

[Reinhard Tartler]

I've been looking at this test failure, but remain puzzled.

Basically, the source for this test is here:
https://sources.debian.org/src/docker.io/20.10.25%2Bdfsg1-2/engine/distribution/xfer/download_test.go/#L364-L429.
This test is testing code in
https://sources.debian.org/src/docker.io/20.10.25+dfsg1-2/engine/distribution/xfer/download.go
which has only two external dependencies
(golang-github-docker-distribution-dev) and
(golang-github-sirupsen-logrus-dev).

I've checked the build log of the previous build at
https://buildd.debian.org/status/fetch.php?pkg=docker.io=amd64=20.10.25%2Bdfsg1-2%2Bb3=1704672923=0
and note that the same test passes in that build. This also uses the same
package versions of golang-github-docker-distribution-dev==2.8.2+ds1-1 and
golang-github-sirupsen-logrus-dev==1.9.0-1

I also note that the old build was using golang 1.21, and the FTBFS was
introduced after upgrading unstable to golang 1.22.

Shengjing, I believe you handled the recent update of the golang toolchain
from 1.21 to 1.22. Have you seen similar "mysterious" test failures that
resulted from using a newer golang compiler?

I am considering just disabling this test, as the rest of the testsuite
seem to pass, but I'm getting nervous that this wouldn't just paper over a
real issue.

Thanks,


-- 
regards,
Reinhard

Bug#1069180: rust-tonic: Please update to tonic 0.11 in experimental

[Reinhard Tartler]

Package: librust-tonic-build-dev
Severity: normal
X-Debbugs-Cc: none, Reinhard Tartler 

Hi Jonas,

I've just uploaded rust-prost to version 0.12 in experimental. Can you
please update rust-tonic to 0.11 that builds against it?

I am working on another package (netavark, which is required for podman
5.0) that requires updated versions of both packages.

Thanks for your assistance!
-rt


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1068136: Accepted golang-google-protobuf 1.33.0-1 (source) into unstable

[Reinhard Tartler]

Package: golang-google-protobuf
Version: 1.33.0-1

Hey Anthony,

I noticed that this upload breaks autopkgtest
for golang-github-golang-protobuf-1-5, cf.
https://tracker.debian.org/pkg/golang-google-protobuf

40s # github.com/golang/protobuf/protoc-gen-go/descriptor
682

40s src/
github.com/golang/protobuf/protoc-gen-go/descriptor/descriptor.pb.go:106:61:
undefined: descriptorpb.Default_FileOptions_PhpGenericServices
683

40s google.golang.org/protobuf/reflect/protodesc
684

do you know what's going on here?

This seems to block migration of quite a few other packages, including
security updates for buildah and libpod.

-rt



On Tue, Mar 26, 2024 at 8:21 PM Debian FTP Masters <
ftpmas...@ftp-master.debian.org> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Format: 1.8
> Date: Tue, 26 Mar 2024 17:49:06 -0600
> Source: golang-google-protobuf
> Architecture: source
> Version: 1.33.0-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Go Packaging Team 
> Changed-By: Anthony Fok 
> Closes: 1065684
> Changes:
>  golang-google-protobuf (1.33.0-1) unstable; urgency=medium
>  .
>* New upstream version 1.33.0
>  .
>  encoding/protojson, internal/encoding/json: handle missing object
> values
>  .
>  In internal/encoding/json, report an error when encountering a }
>  when we are expecting an object field value. For example, the input
>  `{"":}` now correctly results in an error at the closing } token.
>  .
>  In encoding/protojson, check for an unexpected EOF token in
>  skipJSONValue. This is redundant with the check in
> internal/encoding/json,
>  but adds a bit more defense against any other similar bugs that
>  might exist.
>  .
>  Fixes CVE-2024-24786 (Closes: #1065684)
>  .
>* DH_GOLANG_INSTALL_EXTRA: Update path to editions_defaults.binpb
>  which was moved from reflect/protodesc/ to internal/editiondefaults/
> Checksums-Sha1:
>  b4aaad31d00d1ab4eccdbf8624d3b7831a3ab61a 2381
> golang-google-protobuf_1.33.0-1.dsc
>  9673951a743296d76d1a474871c2443f7a449ffc 812348
> golang-google-protobuf_1.33.0.orig.tar.xz
>  5a249134d9e0c499bd70f8978155a5ccd2573eaf 4060
> golang-google-protobuf_1.33.0-1.debian.tar.xz
>  d65004dfe310321fe0bfacd5a7a9ff8f2bcf15bd 6838
> golang-google-protobuf_1.33.0-1_amd64.buildinfo
> Checksums-Sha256:
>  1274db27a31a56d97a94efd04ed288922bbe8dcc46cf2e805ced2cd423bb8a01 2381
> golang-google-protobuf_1.33.0-1.dsc
>  40d83211cdfc25e1c13c6de527b33516c21d6ef48188070ff22f29330abe4f84 812348
> golang-google-protobuf_1.33.0.orig.tar.xz
>  9469684733b7810b2a382ea2c0e801c4b0b4bd90bc41399e3a76d8760996ac03 4060
> golang-google-protobuf_1.33.0-1.debian.tar.xz
>  ce0906317aab1c72969211523151d466ac98416e798139c8a7eec0eacefb6aa7 6838
> golang-google-protobuf_1.33.0-1_amd64.buildinfo
> Files:
>  9f76d0ea63ae9eb01ff3917847cd8ebc 2381 golang optional
> golang-google-protobuf_1.33.0-1.dsc
>  e102870db4b3dfb32af3ee85f427acad 812348 golang optional
> golang-google-protobuf_1.33.0.orig.tar.xz
>  b7485bec7ce51cb4b820b7c0df1c3a6e 4060 golang optional
> golang-google-protobuf_1.33.0-1.debian.tar.xz
>  1e8b2ecc9959e7a38402e295616a05ef 6838 golang optional
> golang-google-protobuf_1.33.0-1_amd64.buildinfo
>
> -BEGIN PGP SIGNATURE-
>
> iQJEBAEBCAAuFiEEFCQhsZrUqVmW+VBy6iUAtBLFms8FAmYDYDAQHGZva2FAZGVi
> aWFuLm9yZwAKCRDqJQC0EsWazzzsD/sGWkFsY9HxvjV+I3uOVIJFVNXno5jjvq+K
> r4gn+iZeL6lXXZEUe5i0o+qBAoLdTCQ0e7LYnDLxQVrlWi7NgVvME75O0TjsMX3s
> F+eevszYhb0MKeXq0VFmBDv+ZHVQoVgsom/2QDzJ9G70M1FIYc4QjQ/cQZ3DtyLc
> SOf6J/520TdIIx4SC8ht54874GVxehBCSBk+ZRh4qnJc8OZfgg6qISEy3zhzov12
> AEPc7E2mmjZJwF16V9X6MMRJteEy4j4fTfEQ9GpQ+Gg9rnXwYSupuSINISQ8adiV
> t8K7NCy9SZh/SIkUjTXcHskobTlUmajpBzDfJvl/W/1+nnZKjcHfMq9JcS0T7pyf
> Nee3zubnjdIA9212hO27ygJcoQrPNsZ2yhLEn74NMY8W+z5u15qtqi6qlQ/xVcb3
> kwvOtzd3pIUcD+RbN4w1tKcD5ATW5Tlo2awt7DkKHOAtbXNf42N2/jlJbHWeMjgB
> wDHFH0lVs7mZQT16glt8cvSZPjJyqPKzeVfAR2rnkBz162qjNLndeycyyGGXS9Wd
> gWvu/Yk3VJyf8N5g8Qb+EVJQxX6XPXSaWWMaxaSaJ8PBVW1V2+hPEuseuLY0sZHV
> 4kk0e4GtlzbMRDuDTm3Yq4XWVFiwLbtl4kw07u0QpHW9vRmLwClnDa0REJ4aGtih
> idTusSuIxg==
> =Ph/5
> -END PGP SIGNATURE-
>
>

-- 
regards,
Reinhard

Bug#1067800: golang-github-containers-buildah: CVE-2024-1753

[Reinhard Tartler]

I've uploaded a fixed version of buildah to sid yesterday, and a new
upstream version of libpod that builds against the fixed buildah just now.

thanks for filing this report, I believe we should be all set now once the
builds reach the archive.

On Tue, Mar 26, 2024 at 6:00 PM Salvatore Bonaccorso 
wrote:

> Source: golang-github-containers-buildah
> Version: 1.33.5+ds1-4
> Severity: important
> Tags: security upstream
> X-Debbugs-Cc: car...@debian.org, Debian Security Team <
> t...@security.debian.org>
>
> Hi,
>
> The following vulnerability was published for
> golang-github-containers-buildah.
>
> CVE-2024-1753[0]:
> | A flaw was found in Buildah (and subsequently Podman Build) which
> | allows containers to mount arbitrary locations on the host
> | filesystem into build containers. A malicious Containerfile can use
> | a dummy image with a symbolic link to the root filesystem as a mount
> | source and cause the mount operation to mount the host root
> | filesystem inside the RUN step. The commands inside the RUN step
> | will then have read-write access to the host filesystem, allowing
> | for full container escape at build time.
>
>
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
>
> For further information see:
>
> [0] https://security-tracker.debian.org/tracker/CVE-2024-1753
> https://www.cve.org/CVERecord?id=CVE-2024-1753
> [1]
> https://github.com/containers/buildah/security/advisories/GHSA-pmf3-c36m-g5cf
>
> Please adjust the affected versions in the BTS as needed.
>
> Regards,
> Salvatore
>
>

-- 
regards,
Reinhard

Bug#1067503: ITP: golang-github-crc-org-crc -- Helper tool for running containers

[Reinhard Tartler]

Package: wnpp
Owner: Reinhard Tartler 
Severity: wishlist

* Package name: golang-github-crc-org-crc
  Version : 2.34.0-1
  Upstream Author : CRC Runs Containers
* URL : https://github.com/crc-org/crc
* License : Apache-2.0
  Programming Lang: Go
  Description : Helper tool for running run containers.

New dependency of podman 5.0

Bug#1067503: ITP: golang-github-crc-org-crc -- Helper tool for running containers

[Reinhard Tartler]

Package: wnpp
Owner: Reinhard Tartler 
Severity: wishlist

* Package name: golang-github-crc-org-crc
  Version : 2.34.0-1
  Upstream Author : CRC Runs Containers
* URL : https://github.com/crc-org/crc
* License : Apache-2.0
  Programming Lang: Go
  Description : Helper tool for running run containers.

New dependency of podman 5.0

[pkg-go] Bug#1067186: Fwd: [Podman] Podman v5.0.0 Released

[Reinhard Tartler]

Package: libpod
Severity: wishlist

-- Forwarded message -
From: Matt Heon 
Date: Tue, Mar 19, 2024, 19:13
Subject: [Podman] Podman v5.0.0 Released
To: , Podman List 


Hi all,

Podman v5.0.0 has just been released. This is our first major version bump
in two years, and comes with a large number of new features and swapped
defaults, including a complete rewrite of `podman machine` to improve
stability and performance. Full details are available in the release notes
[1].

We've been working on 5.0 for months now and are excited to get it out into
people's hands. Try it out and let us know what you think!

Thanks,
Matt Heon

[1] https://github.com/containers/podman/releases/tag/v5.0.0
___
Podman mailing list -- pod...@lists.podman.io
To unsubscribe send an email to podman-le...@lists.podman.io
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Bug#1067186: Fwd: [Podman] Podman v5.0.0 Released

[Reinhard Tartler]

Package: libpod
Severity: wishlist

-- Forwarded message -
From: Matt Heon 
Date: Tue, Mar 19, 2024, 19:13
Subject: [Podman] Podman v5.0.0 Released
To: , Podman List 


Hi all,

Podman v5.0.0 has just been released. This is our first major version bump
in two years, and comes with a large number of new features and swapped
defaults, including a complete rewrite of `podman machine` to improve
stability and performance. Full details are available in the release notes
[1].

We've been working on 5.0 for months now and are excited to get it out into
people's hands. Try it out and let us know what you think!

Thanks,
Matt Heon

[1] https://github.com/containers/podman/releases/tag/v5.0.0
___
Podman mailing list -- pod...@lists.podman.io
To unsubscribe send an email to podman-le...@lists.podman.io

Re: Backporting podman

[Reinhard Tartler]

Great analysis, thanks for the writeup.

As the person who has packaged podman for sid, I'm afraid I have to point
out that the "fun" doesn't end here. In addition to podman, you'll also be
looking at backporting:

- runc (potentially crun, which may or may not be easier)
- conmon
- aardvark/netavark (alternatively, passt/pasta for user-space networking)

But as Matthias said, most of the work is fairly mechanical.

It is the sheer amount of packages that would also need to be kept
uptodate in backports that keeps me from updating the package in backports.
But, if we found enough interested and reliable contributors, it is doable.
And also quite straightforward to do if we can agree to maintain "backport"
branches in the git repositories on salsa, and keep some discipline in
keeping them up to date.

what do you think?

On Sat, Feb 10, 2024 at 6:01 PM Mathias Gibbens  wrote:

> Hi Krumelmonster and Simon,
>
> On Sat, 2024-02-10 at 12:02 +0100, Simon Josefsson wrote:
> > Krumelmonster  writes:
> > > I would like to see podman>=4.4 make it into bookworm backports so the
> > > excellent quadlet feature would become available in debian stable. I'm
> > > inexperienced in debian packaging and gave up on my first attempt in
> > > creating this backport due to the sheer number of (indirect)
> > > dependencies missing in bookworm.
> > >
> > > Only after that have I learned about dh-make-golang but it is unclear
> > > to me whether or how I could use it to create the backports.
> > >
> > > Has someone looked into backporting podman before and where there
> issues?
> > > Are there any instructions on how to backport go packages in
> > > particular? What could be my starting point for attempting this?
> > >
> > > I would be very happy if someone else took the time to create the
> > > backport but it is important enough to me to attempt the backport
> > > myself and ask for sponsorship should it succeed. In that case, any
> > > advice would be welcome.
> >
> > Hi.  I'm a go packaging newbie, but would also like to see this.  I tend
> > to install unofficial podman (e.g., [1]) when the available podman is
> > too old, and working on official backports could help.
> >
> > I think you can simply try to build the current podman packages from
> > testing in a bookworm chroot, and then fix whatever breakage there is.
> > Most likely you will need to backport a number of reverse dependencies
> > to get podman to build.  There is no need to use dh-make-golang which is
> > used to create a new package.  I'm happy to help, but my spare cycles to
> > work on Go packages are stocastic and limited.
>
>   On the one hand, backporting golang packages is relatively easy,
> because most of the golang packages in Debian simply contain the source
> required to build other golang packages so the risk of breaking a
> stable system is low. On the other hand, there tend to be a _ton_ of
> golang libraries when you look at the dependencies for a package like
> src:libpod.
>
>   Backport policy[1] requires that only versions of packages in testing
> can be backported. This means there shouldn't be any need to create new
> packages; rather, you can (most of the time) just do (as a very simple
> example) a `dget  && dch --bpo && debuild`
> in the appropriate environment (ie, a bookworm chroot/container/VM).
> Packages maintained within the Go Packaging Team tend to follow
> DEP14[2] for package git repos.
>
>   So, let's take a quick look at the top-level dependencies missing
> from bookworm -- aka, roughly how much work will backporting be? For
> src:libpod 4.9.2+ds1-2, trying to use `git-buildpackage` to build the
> package for bookworm I get the following:
>
> > The following packages have unmet dependencies:
> >  pbuilder-satisfydepends-dummy : Depends:
> golang-github-checkpoint-restore-checkpointctl-dev which is a virtual
> package and is not provided by any available package
> >  Depends:
> golang-github-checkpoint-restore-go-criu-dev (> 6) but 5.3.0-2 is to be
> installed
> >  Depends:
> golang-github-containers-buildah-dev (>= 1.33.5) but it is not going to be
> installed
> >  Depends:
> golang-github-containers-common-dev (>= 0.57.4) but it is not going to be
> installed
> >  Depends:
> golang-github-containers-image-dev (>= 5.29.2~) but it is not going to be
> installed
> >  Depends:
> golang-github-containers-storage-dev (>= 1.51) but 1.43.0+ds1-8 is to be
> installed
> >  Depends:
> golang-github-containers-gvisor-tap-vsocks-dev which is a virtual package
> and is not provided by any available package
> >  Depends:
> golang-github-coreos-stream-metadata-go-dev which is a virtual package and
> is not provided by any available package
> >  Depends:
> 

Bug#1062598: libpod: Add support for LoongArch

[Reinhard Tartler]

Control: forwarded -1 https://github.com/containers/podman/pull/21481
Control: severity -1 minor

On Mon, Feb 5, 2024 at 5:51 AM Faidon Liambotis  wrote:

> On Mon, Feb 05, 2024 at 02:13:50PM +0800, 张家岭 wrote:
> >  Hi, this can support loong64 build , Ｉ build this in my local . and
> I'll submit to upstream .
>
>
That's amazing, congrats on getting podman to work on longsson, and thanks
for submitting your patch to https://github.com/containers/podman/pull/21481

But is your patch necessary to build for loong64? Does the build fail
> without your patch?
>

I think Faidon is right and your patch is not strictly necessary for
building the package. If you look at
https://buildd.debian.org/status/package.php?p=libpod, there are builds for
mips and mipsel without a similar patch. I guess that podman machine won't
set the default image architecture properly. This is probably not an issue
for typical podman usage. Or do you plan running podman-machine managed
virtual machines on mips/loongson based board?


-- 
regards,
Reinhard

[pkg-go] Bug#1062598: libpod: Add support for LoongArch

[Reinhard Tartler]

Control: forwarded -1 https://github.com/containers/podman/pull/21481
Control: severity -1 minor

On Mon, Feb 5, 2024 at 5:51 AM Faidon Liambotis  wrote:

> On Mon, Feb 05, 2024 at 02:13:50PM +0800, 张家岭 wrote:
> >  Hi, this can support loong64 build , Ｉ build this in my local . and
> I'll submit to upstream .
>
>
That's amazing, congrats on getting podman to work on longsson, and thanks
for submitting your patch to https://github.com/containers/podman/pull/21481

But is your patch necessary to build for loong64? Does the build fail
> without your patch?
>

I think Faidon is right and your patch is not strictly necessary for
building the package. If you look at
https://buildd.debian.org/status/package.php?p=libpod, there are builds for
mips and mipsel without a similar patch. I guess that podman machine won't
set the default image architecture properly. This is probably not an issue
for typical podman usage. Or do you plan running podman-machine managed
virtual machines on mips/loongson based board?


-- 
regards,
Reinhard
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

[pkg-go] Bug#1062529: Fwd: [containers/podman] Release v4.9.1 - v4.9.1

[Reinhard Tartler]

Package: libpod
Severity: wishlist

-- Forwarded message -
From: Ashley Cui 
Date: Thu, Feb 1, 2024, 09:12
Subject: [containers/podman] Release v4.9.1 - v4.9.1
To: containers/podman 
Cc: Subscribed 


v4.9.1 

Repository: containers/podman  · Tag:
v4.9.1  · Commit: 118829d

· Released by: ashley-cui 
Bugfixes

   - Fixed a bug where the --rootful option to podman machine set would not
   set the machine to use the root connection (#21195
   ).
   - Fixed a bug where podman would crash when running in a containerized
   environment with euid != 0 and capabilities set (#20766
   ).
   - Fixed a bug where the podman info command would crash on if called
   multiple times when podman was running as euid=0 without CAP_SYS_ADMIN (
   #20908 ).
   - Fixed a bug where podman machine commands were not relayed to the
   correct machine on AppleHV (#21115
   ).
   - Fixed a bug where the podman machine list and podman machine inspect
   commands would not show the correct Last Up time on AppleHV (#21244
   ).

Misc

   - Updated the Mac pkginstaller QEMU to v8.2.1
   - Updated Buildah to v1.33.4
   - Updated the containers/image library to v5.29.2
   - Updated the containers/common library to v0.57.3

—

This release has 8 assets:

   - podman-remote-release-darwin_amd64.zip
   - podman-remote-release-darwin_arm64.zip
   - podman-remote-release-windows_amd64.zip
   - podman-remote-static-linux_amd64.tar.gz
   - podman-remote-static-linux_arm64.tar.gz
   - shasums
   - Source code (zip)
   - Source code (tar.gz)

Visit the release page
 to download them.

—
You are receiving this because you are watching this repository.
View it on GitHub 
or unsubscribe

from all notifications for this repository.
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Bug#1062529: Fwd: [containers/podman] Release v4.9.1 - v4.9.1

[Reinhard Tartler]

Package: libpod
Severity: wishlist

-- Forwarded message -
From: Ashley Cui 
Date: Thu, Feb 1, 2024, 09:12
Subject: [containers/podman] Release v4.9.1 - v4.9.1
To: containers/podman 
Cc: Subscribed 


v4.9.1 

Repository: containers/podman  · Tag:
v4.9.1  · Commit: 118829d

· Released by: ashley-cui 
Bugfixes

   - Fixed a bug where the --rootful option to podman machine set would not
   set the machine to use the root connection (#21195
   ).
   - Fixed a bug where podman would crash when running in a containerized
   environment with euid != 0 and capabilities set (#20766
   ).
   - Fixed a bug where the podman info command would crash on if called
   multiple times when podman was running as euid=0 without CAP_SYS_ADMIN (
   #20908 ).
   - Fixed a bug where podman machine commands were not relayed to the
   correct machine on AppleHV (#21115
   ).
   - Fixed a bug where the podman machine list and podman machine inspect
   commands would not show the correct Last Up time on AppleHV (#21244
   ).

Misc

   - Updated the Mac pkginstaller QEMU to v8.2.1
   - Updated Buildah to v1.33.4
   - Updated the containers/image library to v5.29.2
   - Updated the containers/common library to v0.57.3

—

This release has 8 assets:

   - podman-remote-release-darwin_amd64.zip
   - podman-remote-release-darwin_arm64.zip
   - podman-remote-release-windows_amd64.zip
   - podman-remote-static-linux_amd64.tar.gz
   - podman-remote-static-linux_arm64.tar.gz
   - shasums
   - Source code (zip)
   - Source code (tar.gz)

Visit the release page
 to download them.

—
You are receiving this because you are watching this repository.
View it on GitHub 
or unsubscribe

from all notifications for this repository.

Bug#1061032: Not reproducible

[Reinhard Tartler]

Control: severity -1 normal
Control: tags -1 unreproducible

Hey Lucas,

I've been unable to reproduce, please see my build log attached to this email.
Maybe some test is flaky?

I'm lowering severity as I am unconvinced that removing this package from
testing, along with all of its reverse dependencies is doing anyone a
service.

<#part type="text/plain" 
filename="/srv/scratch/packages/go-team/golang-github-go-kit-kit.autopkgtest.log/log"
 disposition=inline description="successful build log">
<#/part>

Bug#1061032: Not reproducible

[Reinhard Tartler]

Control: severity -1 normal
Control: tags -1 unreproducible

Hey Lucas,

I've been unable to reproduce, please see my build log attached to this email.
Maybe some test is flaky?

I'm lowering severity as I am unconvinced that removing this package from
testing, along with all of its reverse dependencies is doing anyone a
service.

<#part type="text/plain" 
filename="/srv/scratch/packages/go-team/golang-github-go-kit-kit.autopkgtest.log/log"
 disposition=inline description="successful build log">
<#/part>

Bug#1061383: Fwd: [Podman] Podman v4.9.0 Released

[Reinhard Tartler]

Package: libpod
Severity: wishlist

-- Forwarded message -
From: Ashley Cui 
Date: Mon, Jan 22, 2024, 21:00
Subject: [Podman] Podman v4.9.0 Released
To: , 


We’re excited to announce that Podman v4.9.0 has been released! Here's
what's new:

Features

   - The podman farm suite of commands for multi-architecture builds is now
   fully enabled and documented.
   - Add a network recovery service to Podman Machine VMs using the QEMU
   backend to detect and recover from an inoperable host networking issues
   experienced by Mac users when running for long periods of time.

Bugfixes

   - Fixed a bug where the HyperV provider for podman machine did not
   forward the API socket to the host machine.
   - Fixed a bug where improperly formatted annotations passed to podman
   kube play could cause Podman to panic.
   - Fixed a bug where podman system reset could fail if non-Podman
   containers (e.g. containers created by Buildah) were present.

Misc

   - Containers run in podman machine VMs now default to a PID limit of
   unlimited, instead of 2048.

 Try it out and let us know what you think!


-- 
Ashley Cui
___
Podman mailing list -- pod...@lists.podman.io
To unsubscribe send an email to podman-le...@lists.podman.io

[pkg-go] Bug#1061383: Fwd: [Podman] Podman v4.9.0 Released

[Reinhard Tartler]

Package: libpod
Severity: wishlist

-- Forwarded message -
From: Ashley Cui 
Date: Mon, Jan 22, 2024, 21:00
Subject: [Podman] Podman v4.9.0 Released
To: , 


We’re excited to announce that Podman v4.9.0 has been released! Here's
what's new:

Features

   - The podman farm suite of commands for multi-architecture builds is now
   fully enabled and documented.
   - Add a network recovery service to Podman Machine VMs using the QEMU
   backend to detect and recover from an inoperable host networking issues
   experienced by Mac users when running for long periods of time.

Bugfixes

   - Fixed a bug where the HyperV provider for podman machine did not
   forward the API socket to the host machine.
   - Fixed a bug where improperly formatted annotations passed to podman
   kube play could cause Podman to panic.
   - Fixed a bug where podman system reset could fail if non-Podman
   containers (e.g. containers created by Buildah) were present.

Misc

   - Containers run in podman machine VMs now default to a PID limit of
   unlimited, instead of 2048.

 Try it out and let us know what you think!


-- 
Ashley Cui
___
Podman mailing list -- pod...@lists.podman.io
To unsubscribe send an email to podman-le...@lists.podman.io
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Bug#1061074: ITP: golang-github-hugelgupf-p9 -- p9 implementation written in golang

[Reinhard Tartler]

Package: wnpp
Owner: Reinhard Tartler 
Severity: wishlist

* Package name: golang-github-hugelgupf-p9
  Version : 0.3.0
  Upstream Author : gvisor authors
* URL or Web page : https://github.com/hugelgupf/p9
* License : Apache 2.0
  Description : p9 implementation written in golang

This package provides a p9 server and client implementation written in
 golang. It is part of the gvisor security platform.

Intend to maintain this under the pkg-golang umbrella. It is a new
dependency of podman (used by podman machine to transfer files to VMs it
manages).

Bug#1061074: ITP: golang-github-hugelgupf-p9 -- p9 implementation written in golang

[Reinhard Tartler]

Package: wnpp
Owner: Reinhard Tartler 
Severity: wishlist

* Package name: golang-github-hugelgupf-p9
  Version : 0.3.0
  Upstream Author : gvisor authors
* URL or Web page : https://github.com/hugelgupf/p9
* License : Apache 2.0
  Description : p9 implementation written in golang

This package provides a p9 server and client implementation written in
 golang. It is part of the gvisor security platform.

Intend to maintain this under the pkg-golang umbrella. It is a new
dependency of podman (used by podman machine to transfer files to VMs it
manages).

Bug#1061074: ITP: golang-github-hugelgupf-p9 -- p9 implementation written in golang

[Reinhard Tartler]

Package: wnpp
Owner: Reinhard Tartler 
Severity: wishlist

* Package name: golang-github-hugelgupf-p9
  Version : 0.3.0
  Upstream Author : gvisor authors
* URL or Web page : https://github.com/hugelgupf/p9
* License : Apache 2.0
  Description : p9 implementation written in golang

This package provides a p9 server and client implementation written in
 golang. It is part of the gvisor security platform.

Intend to maintain this under the pkg-golang umbrella. It is a new
dependency of podman (used by podman machine to transfer files to VMs it
manages).

Bug#1060820: ITP: golang-github-cyberphone-json-canonicalization -- JSON Canonicalization Scheme (JCS) (Go library)

[Reinhard Tartler]

On Sun, Jan 14, 2024 at 8:36 PM Simon Josefsson  wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Simon Josefsson 
>
> * Package name: golang-github-cyberphone-json-canonicalization
>   Version : 0.0~git20220623.57a0ce2-1
>   Upstream Author : Anders Rundgren
> * URL : https://github.com/cyberphone/json-canonicalization
> * License : Apache-2.0
>   Programming Lang: Go
>   Description : JSON Canonicalization Scheme (JCS) (Go library)
>
>
I contemplated packaging this library in the past, but found it actually
contains
a lot of other stuff I didn't nede. In the end, I ended up packaging
https://salsa.debian.org/debian/golang-webpki-org-jsoncanonicalizer
which seems to be what the proposed package is "repackaing".

In a way, I went straight for the source, I guess.

Best,
-rt

Bug#1060820: ITP: golang-github-cyberphone-json-canonicalization -- JSON Canonicalization Scheme (JCS) (Go library)

[Reinhard Tartler]

On Sun, Jan 14, 2024 at 8:36 PM Simon Josefsson  wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Simon Josefsson 
>
> * Package name: golang-github-cyberphone-json-canonicalization
>   Version : 0.0~git20220623.57a0ce2-1
>   Upstream Author : Anders Rundgren
> * URL : https://github.com/cyberphone/json-canonicalization
> * License : Apache-2.0
>   Programming Lang: Go
>   Description : JSON Canonicalization Scheme (JCS) (Go library)
>
>
I contemplated packaging this library in the past, but found it actually
contains
a lot of other stuff I didn't nede. In the end, I ended up packaging
https://salsa.debian.org/debian/golang-webpki-org-jsoncanonicalizer
which seems to be what the proposed package is "repackaing".

In a way, I went straight for the source, I guess.

Best,
-rt

Bug#1058795: Docker.io breaks libvirt/qemu bridge network

[Reinhard Tartler]

Control: severity -1 minor
Control: tag -1 wontfix
Control: retitle -1 Docker.io breaks libvirt/qemu bridge network

Please review the package's postinst script to convince yourself that the 
Debian docker.io package does not ship any firewall rules:

https://salsa.debian.org/go-team/packages/docker/-/blob/master/debian/docker.io.postinst?ref_type=heads

However, the docker.io package does indeed manipulate iptables rules to provide 
container isolation. This is a well-known and documented feature at 
https://docs.docker.com/network/packet-filtering-firewalls/

The particular issue that you are experiencing is probably  described best at 
https://serverfault.com/questions/963759/docker-breaks-libvirt-bridge-network. 
That article also container an detailed description on why this is actually a 
feature and how to work around it.

On a personal note, consider installing the 'podman-docker' package instead of 
the 'docker.io' package, this might be sufficient depending on your use-case.

I'm leaving this bug open as I'm not the regular maintainer of the docker.io 
package. Probably this should be documented in the README.md file or similar.

Happy Holidays,
-rt

Bug#1058795: Docker.io breaks libvirt/qemu bridge network

[Reinhard Tartler]

Control: severity -1 minor
Control: tag -1 wontfix
Control: retitle -1 Docker.io breaks libvirt/qemu bridge network

Please review the package's postinst script to convince yourself that the 
Debian docker.io package does not ship any firewall rules:

https://salsa.debian.org/go-team/packages/docker/-/blob/master/debian/docker.io.postinst?ref_type=heads

However, the docker.io package does indeed manipulate iptables rules to provide 
container isolation. This is a well-known and documented feature at 
https://docs.docker.com/network/packet-filtering-firewalls/

The particular issue that you are experiencing is probably  described best at 
https://serverfault.com/questions/963759/docker-breaks-libvirt-bridge-network. 
That article also container an detailed description on why this is actually a 
feature and how to work around it.

On a personal note, consider installing the 'podman-docker' package instead of 
the 'docker.io' package, this might be sufficient depending on your use-case.

I'm leaving this bug open as I'm not the regular maintainer of the docker.io 
package. Probably this should be documented in the README.md file or similar.

Happy Holidays,
-rt

Bug#1057618: Fwd: [containers/podman] Release v4.8.1 - v4.8.1

[Reinhard Tartler]

I'm currently blocked on packaging this new upstrema version because of a
new dependency that was added in
https://github.com/containers/podman/commit/289e59ee1fbbf95dc5d6b370adf9e951acf157bf

I've packaged github.com/containers/gvisor-tap-vsock and as soon
as #1057435 passes NEW,
expect an upload of 4.8.1 shortly.

[pkg-go] Bug#1057618: Fwd: [containers/podman] Release v4.8.1 - v4.8.1

[Reinhard Tartler]

I'm currently blocked on packaging this new upstrema version because of a
new dependency that was added in
https://github.com/containers/podman/commit/289e59ee1fbbf95dc5d6b370adf9e951acf157bf

I've packaged github.com/containers/gvisor-tap-vsock and as soon
as #1057435 passes NEW,
expect an upload of 4.8.1 shortly.
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Bug#1057618: Fwd: [containers/podman] Release v4.8.1 - v4.8.1

[Reinhard Tartler]

Package: libpod

-- Forwarded message -
From: Lokesh Mandvekar 
Date: Tue, Dec 5, 2023 at 6:49 AM
Subject: [containers/podman] Release v4.8.1 - v4.8.1
To: containers/podman 
Cc: Subscribed 


v4.8.1 

Repository: containers/podman  · Tag:
v4.8.1  · Commit: ef6e5ac

· Released by: lsm5 
Bugfixes

   - Fixed a bug on Windows (WSL) where wsl.conf/resolv.conf was not
   restored when user-mode networking was disabled after being enabled (
   #20625 ).
   - Fixed a bug where currently if user specifies podman kube play
   --replace, the pod is removed on the client side, not the server side (
   #20705 ).
   - Fixed a bug where podman machine rm -f would cause a deadlock when
   running with WSL.
   - Fixed database is locked errors with the new sqlite database backend (
   #20809 ).
   - Fixed a bug where podman-remote exec would fail if the server API
   version is older than 4.8.0 (#20821
   ).
   - Fixed a bug where Podman would not run any command on systems with a
   symlinked $HOME (#20872
   ).

—

This release has 8 assets:

   - podman-remote-release-darwin_amd64.zip
   - podman-remote-release-darwin_arm64.zip
   - podman-remote-release-windows_amd64.zip
   - podman-remote-static-linux_amd64.tar.gz
   - podman-remote-static-linux_arm64.tar.gz
   - shasums
   - Source code (zip)
   - Source code (tar.gz)

Visit the release page
 to download them.

—
You are receiving this because you are watching this repository.
View it on GitHub 
or unsubscribe

from all notifications for this repository.


-- 
regards,
Reinhard

[pkg-go] Bug#1057618: Fwd: [containers/podman] Release v4.8.1 - v4.8.1

[Reinhard Tartler]

Package: libpod

-- Forwarded message -
From: Lokesh Mandvekar 
Date: Tue, Dec 5, 2023 at 6:49 AM
Subject: [containers/podman] Release v4.8.1 - v4.8.1
To: containers/podman 
Cc: Subscribed 


v4.8.1 

Repository: containers/podman  · Tag:
v4.8.1  · Commit: ef6e5ac

· Released by: lsm5 
Bugfixes

   - Fixed a bug on Windows (WSL) where wsl.conf/resolv.conf was not
   restored when user-mode networking was disabled after being enabled (
   #20625 ).
   - Fixed a bug where currently if user specifies podman kube play
   --replace, the pod is removed on the client side, not the server side (
   #20705 ).
   - Fixed a bug where podman machine rm -f would cause a deadlock when
   running with WSL.
   - Fixed database is locked errors with the new sqlite database backend (
   #20809 ).
   - Fixed a bug where podman-remote exec would fail if the server API
   version is older than 4.8.0 (#20821
   ).
   - Fixed a bug where Podman would not run any command on systems with a
   symlinked $HOME (#20872
   ).

—

This release has 8 assets:

   - podman-remote-release-darwin_amd64.zip
   - podman-remote-release-darwin_arm64.zip
   - podman-remote-release-windows_amd64.zip
   - podman-remote-static-linux_amd64.tar.gz
   - podman-remote-static-linux_arm64.tar.gz
   - shasums
   - Source code (zip)
   - Source code (tar.gz)

Visit the release page
 to download them.

—
You are receiving this because you are watching this repository.
View it on GitHub 
or unsubscribe

from all notifications for this repository.


-- 
regards,
Reinhard
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Bug#1057435: ITP: golang-github-containers-gvisor-tap-vsocks -- golang bindings for gvisor

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 
X-Debbugs-Cc: debian-de...@lists.debian.org, siret...@tauware.de

* Package name: golang-github-containers-gvisor-tap-vsocks
  Version : 0.7.1
  Upstream Contact: gvisor-tap-vsocks authors
* URL : https://github.com/containers/gvisor-tap-vsoc
* License : Apache-2.03
  Programming Lang: Golang
  Description : golang bindings for gvisor

this is a new dependencies for podman 4.8

Bug#1057435: ITP: golang-github-containers-gvisor-tap-vsocks -- golang bindings for gvisor

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 
X-Debbugs-Cc: debian-devel@lists.debian.org, siret...@tauware.de

* Package name: golang-github-containers-gvisor-tap-vsocks
  Version : 0.7.1
  Upstream Contact: gvisor-tap-vsocks authors
* URL : https://github.com/containers/gvisor-tap-vsoc
* License : Apache-2.03
  Programming Lang: Golang
  Description : golang bindings for gvisor

this is a new dependencies for podman 4.8

Bug#1057435: ITP: golang-github-containers-gvisor-tap-vsocks -- golang bindings for gvisor

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 
X-Debbugs-Cc: debian-de...@lists.debian.org, siret...@tauware.de

* Package name: golang-github-containers-gvisor-tap-vsocks
  Version : 0.7.1
  Upstream Contact: gvisor-tap-vsocks authors
* URL : https://github.com/containers/gvisor-tap-vsoc
* License : Apache-2.03
  Programming Lang: Golang
  Description : golang bindings for gvisor

this is a new dependencies for podman 4.8

Bug#1057406: ITP: htgolang-github-inetaf-tcpproxy -- Proxy TCP connections based on static rules, HTTP Host headers, and SNI server names

[Reinhard Tartler]

Package: wnpp
Owner: Reinhard Tartler 
Severity: wishlist

* Package name: golang-github-inetaf-tcpproxy
  Version : latest git
  Upstream Author : inet.af authors
* URL or Web page : https://github.com/inetaf/tcpproxy/
* License : Apache 2.0
  Description : Proxy TCP connections based on static rules, HTTP Host 
headers, and SNI server names


Needed as a dependency of golang-gvisor bindings, which is required by podman 
4.8

Bug#1057406: ITP: htgolang-github-inetaf-tcpproxy -- Proxy TCP connections based on static rules, HTTP Host headers, and SNI server names

[Reinhard Tartler]

Package: wnpp
Owner: Reinhard Tartler 
Severity: wishlist

* Package name: golang-github-inetaf-tcpproxy
  Version : latest git
  Upstream Author : inet.af authors
* URL or Web page : https://github.com/inetaf/tcpproxy/
* License : Apache 2.0
  Description : Proxy TCP connections based on static rules, HTTP Host 
headers, and SNI server names


Needed as a dependency of golang-gvisor bindings, which is required by podman 
4.8

Bug#1057406: ITP: htgolang-github-inetaf-tcpproxy -- Proxy TCP connections based on static rules, HTTP Host headers, and SNI server names

[Reinhard Tartler]

Package: wnpp
Owner: Reinhard Tartler 
Severity: wishlist

* Package name: golang-github-inetaf-tcpproxy
  Version : latest git
  Upstream Author : inet.af authors
* URL or Web page : https://github.com/inetaf/tcpproxy/
* License : Apache 2.0
  Description : Proxy TCP connections based on static rules, HTTP Host 
headers, and SNI server names


Needed as a dependency of golang-gvisor bindings, which is required by podman 
4.8

Bug#1056656: dgit: Crash while running dgit rpush-source

[Reinhard Tartler]

On 11/24/23 8:24 AM, Reinhard Tartler wrote:

I've been starting to enjoy `dgit rpush-source` so that I can offload my test
building from my laptop. This works for many repositories/packages, but when it 
fails,
it does so in a way that is very hard to diagnose. 



Just for the record, in this particular instance, passing the argument `--gbp` 
allowed me
to proceed. So I've used this invocation:

  dgit --gbp  rpush-source 
ubuntu-builder:/home/siretart/packages/golang-github-containers-buildah --new 
experimental


Clearly, the diagnostics of the current dgit implementation leaves room for 
improvement.

Thanks for providing dgit and its infrastructure. I has really made working 
with debian source packages much more enjoyable!

-rt

Bug#1056656: dgit: Crash while running dgit rpush-source

[Reinhard Tartler]

Package: dgit
Version: 11.5
Severity: normal

I've been starting to enjoy `dgit rpush-source` so that I can offload my test
building from my laptop. This works for many repositories/packages, but when it 
fails,
it does so in a way that is very hard to diagnose. This is what I end up with:

   siretart@x1:~$ dgit  rpush-source 
builder:/home/siretart/packages/golang-github-containers-buildah --new 
experimental 
   Format `3.0 (quilt)', need to check/update patch stack
   canonical suite name for experimental is rc-buggy
   dgit: split brain (separate dgit view) may be needed (--quilt=gbp).
   dgit view: found cached (commit id b157dabf1cec0b379b95559e28273c403995ae9e)
   dpkg-source: info: using source format '3.0 (quilt)'
   dpkg-source: info: building golang-github-containers-buildah using existing 
./golang-github-containers-buildah_1.33.1+ds1.orig.tar.xz
   dpkg-source: info: using patch list from debian/patches/series
   dpkg-source: info: building golang-github-containers-buildah in 
golang-github-containers-buildah_1.33.1+ds1-1.debian.tar.xz
   dpkg-source: info: building golang-github-containers-buildah in 
golang-github-containers-buildah_1.33.1+ds1-1.dsc
   package seems new, not specifying -v
   dpkg-genchanges: info: including full source code in upload
   no version available from the archive
   
   Package not found in the archive, but has allegedly been pushed using dgit.
   Perhaps the upload is stuck in incoming.  Using the version from git.
   
   dgit: split brain (separate dgit view) may be needed (--quilt=gbp).
   dgit view: found cached (commit id b157dabf1cec0b379b95559e28273c403995ae9e)
   Checking that HEAD includes all changes in archive...
   Declaring that HEAD includes all changes in 1.32.0+ds1-1...
   Made pseudo-merge of 1.32.0+ds1-1 into dgit view.
   checking that golang-github-containers-buildah_1.33.1+ds1-1.dsc corresponds 
to HEAD
   dpkg-source: warning: extracting unsigned source package 
(/home/siretart/packages/golang-github-containers-buildah/../golang-github-containers-buildah_1.33.1+ds1-1.dsc)
   dpkg-source: info: extracting golang-github-containers-buildah in 
golang-github-containers-buildah-1.33.1+ds1
   dpkg-source: info: unpacking 
golang-github-containers-buildah_1.33.1+ds1.orig.tar.xz
   dpkg-source: info: unpacking 
golang-github-containers-buildah_1.33.1+ds1-1.debian.tar.xz
   dpkg-source: info: using patch list from debian/patches/series
   dpkg-source: info: applying manpage-fixes.patch
   dpkg-source: info: applying root-testfail-ignore.patch
   dpkg-source: info: applying avoid-buildkit-checksum.patch
   dpkg-source: info: applying avoid-buildkit-heredoc.patch
   ../golang-github-containers-buildah_1.33.1+ds1-1_source.changes already has 
appropriate .orig(s) (if any)
   Format `3.0 (quilt)', need to check/update patch stack
   Use of uninitialized value in concatenation (.) or string at /usr/bin/dgit 
line 5544.
at /usr/share/perl5/Debian/Dgit.pm line 175.
Debian::Dgit::__ANON__("Use of uninitialized value in concatenation (.) 
or string at "...) called at /usr/bin/dgit line 5544
main::i_resp_want("signed-tag") called at /usr/bin/dgit line 5422
main::i_method("i_resp", "want", "signed-tag") called at /usr/bin/dgit 
line 5474
main::rpush_core("push-source") called at /usr/bin/dgit line 5429
main::cmd_rpush_source() called at /usr/bin/dgit line 8319
   ! Push failed, before we got started.
   ! You can retry the push, after fixing the problem, if you like.
   

What's wrong with /usr/bin/dgit line 5544?


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dgit depends on:
ii  apt2.7.6
ii  ca-certificates20230311
ii  coreutils  9.1-1
ii  curl   8.4.0-2
ii  devscripts 2.23.6
ii  dpkg-dev   1.22.1
ii  dput   1.1.3
ii  git [git-core] 1:2.42.0-1
ii  git-buildpackage   0.9.32
ii  libdpkg-perl   1.22.1
ii  libjson-perl   4.1-1
ii  liblist-moreutils-perl 0.430-2
ii  liblocale-gettext-perl 1.07-6
ii  libtext-csv-perl   2.03-1
ii  libtext-glob-perl  0.11-3
ii  libtext-iconv-perl 1.7-8
ii  libwww-curl-perl   4.17-10
ii  perl [libdigest-sha-perl]  5.36.0-9

Versions of packages dgit recommends:
ii  distro-info-data 0.59
ii  liburi-perl  5.21-1
ii  openssh-client [ssh-client]  1:9.4p1-1

Versions of packages dgit suggests:
ii  sbuild  0.85.4

-- no debconf information

Bug#1056342: RFP: go-jose -- An implementation of JOSE standards (JWE, JWS, JWT) in Go

[Reinhard Tartler]

Package: wnpp
Severity: wishlist

* Package name: go-jose
  Version : 3
  Upstream Author : https://github.com/go-jose/go-jose
* URL or Web page : https://github.com/go-jose/go-jose
* License : Apache 2.0
  Description : An implementation of JOSE standards (JWE, JWS, JWT) in Go

While we already have go-jose.v1 and go-jose.v2 in Debian, both of these
versions have been deprecated upstream in favor of version 3. Other projects 
will
soon migrate to v3, making packaging more complicated than necessary.

Bug#1056342: RFP: go-jose -- An implementation of JOSE standards (JWE, JWS, JWT) in Go

[Reinhard Tartler]

Package: wnpp
Severity: wishlist

* Package name: go-jose
  Version : 3
  Upstream Author : https://github.com/go-jose/go-jose
* URL or Web page : https://github.com/go-jose/go-jose
* License : Apache 2.0
  Description : An implementation of JOSE standards (JWE, JWS, JWT) in Go

While we already have go-jose.v1 and go-jose.v2 in Debian, both of these
versions have been deprecated upstream in favor of version 3. Other projects 
will
soon migrate to v3, making packaging more complicated than necessary.

Bug#1056342: RFP: go-jose -- An implementation of JOSE standards (JWE, JWS, JWT) in Go

[Reinhard Tartler]

Package: wnpp
Severity: wishlist

* Package name: go-jose
  Version : 3
  Upstream Author : https://github.com/go-jose/go-jose
* URL or Web page : https://github.com/go-jose/go-jose
* License : Apache 2.0
  Description : An implementation of JOSE standards (JWE, JWS, JWT) in Go

While we already have go-jose.v1 and go-jose.v2 in Debian, both of these
versions have been deprecated upstream in favor of version 3. Other projects 
will
soon migrate to v3, making packaging more complicated than necessary.

Bug#1055411: kubernetes: Verison 1.20 has reached EOL (maintenance support)

[Reinhard Tartler]

Source: kubernetes
Severity: important
X-Debbugs-Cc: debian-rele...@lists.debian.org

Dear maintainer,

The version of kubectl as currently packaged in Debian has reached EOL.

Looking at https://endoflife.date/kubernetes, the date for the maintenance
period expiered on 28 Feb 2022, which is way beyond a full year.

I don't think such old packages should be in the next stable debian release,
but I'll leave it to the release team about deciding on that.

Please upgrade to a newer version. Also, please consider commenting on the
many existing open bugs on the package


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1055291: golang-github-cilium-ebpf: Breaks compilation on loong64

[Reinhard Tartler]

Source: golang-github-cilium-ebpf
Severity: normal

I noticed that podman doesn't build on loong64 with this being the relevant
part from the build log:

# github.com/cilium/ebpf/internal
src/github.com/cilium/ebpf/internal/vdso.go:64:28: undefined: NativeEndian

Looking at the upstream sources, I believe this commit should fix that:

https://github.com/cilium/ebpf/commit/00ec3bb28e0c3158e45080f929c51377499835c9

Currently, debian ships version 0.9.1, the patch above was merged for the v0.11
release.



-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1055059: nmu: runc_1.1.5+ds1-1+b4

[Reinhard Tartler]

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#1055059: nmu: runc_1.1.5+ds1-1+b4

[Reinhard Tartler]

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#1054755: closing 1054755

[Reinhard Tartler]

close 1054755 4.7.1+ds4-4
thanks

Fixed in earlier upload

Bug#1054460: marked as pending in libpod

[Reinhard Tartler]

Control: tag -1 pending

Hello,

Bug #1054460 in libpod reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/libpod/-/commit/6cd165bbd5b60cc9e5f63417ecd80f89b788fa34


avoid file conflicts with docker-compose (Closes: #1054460)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1054460

Bug#1054518: ITP: golang-github-docker-go-plugins-helpers -- A collection of helper packages to extend Docker Engine in Go

[Reinhard Tartler]

Package: wnpp
Owner: Reinhard Tartler 
Severity: wishlist

* Package name: golang-github-docker-go-plugins-helpers
  Version : git
  Upstream Author : Docker, Inc.
* URL or Web page : https://github.com/docker/go-plugins-helpers
* License : Apache 2.0 or Expat
  Description : A collection of helper packages to extend Docker Engine in 
Go

This package is a dependency of podman that I'm trying to unvendor.
I plan to maintain it under the pkg-golang umbrella

Bug#1054518: ITP: golang-github-docker-go-plugins-helpers -- A collection of helper packages to extend Docker Engine in Go

[Reinhard Tartler]

Package: wnpp
Owner: Reinhard Tartler 
Severity: wishlist

* Package name: golang-github-docker-go-plugins-helpers
  Version : git
  Upstream Author : Docker, Inc.
* URL or Web page : https://github.com/docker/go-plugins-helpers
* License : Apache 2.0 or Expat
  Description : A collection of helper packages to extend Docker Engine in 
Go

This package is a dependency of podman that I'm trying to unvendor.
I plan to maintain it under the pkg-golang umbrella

Bug#1054518: ITP: golang-github-docker-go-plugins-helpers -- A collection of helper packages to extend Docker Engine in Go

[Reinhard Tartler]

Package: wnpp
Owner: Reinhard Tartler 
Severity: wishlist

* Package name: golang-github-docker-go-plugins-helpers
  Version : git
  Upstream Author : Docker, Inc.
* URL or Web page : https://github.com/docker/go-plugins-helpers
* License : Apache 2.0 or Expat
  Description : A collection of helper packages to extend Docker Engine in 
Go

This package is a dependency of podman that I'm trying to unvendor.
I plan to maintain it under the pkg-golang umbrella

Re: Updating golang-github-checkpoint-restore-go-criu to v6

[Reinhard Tartler]

Hi Mathias,

On Mon, Oct 16, 2023 at 8:15 AM Reinhard Tartler  wrote:

>
>
> On Thu, Oct 12, 2023 at 11:04 PM Mathias Gibbens 
> wrote:
>
>> [...] the
>> upstream main branch has switched to v6. Attempting to patch runc to
>> use v6 in Debian seems too invasive, and I don't know how long it will
>> be until runc releases a version that uses v6.
>>
>
> Looking ta
> https://github.com/opencontainers/runc/commit/fbce47a6b67bad0da33ea9c17a4ade0ccd89d6cd
> it seems that the bulk of the diff is part of the vendor/ directory, which
> we would ignore for a debian patch anyways. The actual patch appears to be
> touching only import lines in 3 .go files of the upstream source. I must be
> missing something because that doesn't look invasive at all. Can you
> elaborate on why you feel that's not a good approach?
>
I think I've done exactly that in
https://salsa.debian.org/go-team/packages/runc/-/commits/experimental

Can you (and possibly Shengjing) try to run the
https://salsa.debian.org/go-team/packages/runc/-/blob/experimental/debian/tests/integration
against the go-criu 6.3.0 from experimental and let me know if that passes?
If so, I'd suggest to go ahead and upload to experimental, which should
pave the road to having both in unstable.

what do you think?


-- 
regards,
Reinhard

Bug#1054273: ITP: golang-github-checkpoint-restore-checkpointctl -- Tool to inspect Kubernetes and Podman checkpoints

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-checkpoint-restore-checkpointctl
  Version : 1.1.0-1
  Upstream Author : 
* URL : https://github.com/checkpoint-restore/checkpointctl
* License : Apache-2.0
  Programming Lang: Go
  Description : Tool to inspect Kubernetes and Podman checkpoints

 Container engines like *Podman* and *CRI-O* have the ability to
 checkpoint a container.  All data related to a checkpoint is collected
 in a checkpoint archive. With the help of this tool, checkpointctl, it
 is possible to display information about these checkpoint archives.

This is a dependency of podman. I plan to maintain it as part of the
pkg-golang team umbrella

Bug#1054273: ITP: golang-github-checkpoint-restore-checkpointctl -- Tool to inspect Kubernetes and Podman checkpoints

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-checkpoint-restore-checkpointctl
  Version : 1.1.0-1
  Upstream Author : 
* URL : https://github.com/checkpoint-restore/checkpointctl
* License : Apache-2.0
  Programming Lang: Go
  Description : Tool to inspect Kubernetes and Podman checkpoints

 Container engines like *Podman* and *CRI-O* have the ability to
 checkpoint a container.  All data related to a checkpoint is collected
 in a checkpoint archive. With the help of this tool, checkpointctl, it
 is possible to display information about these checkpoint archives.

This is a dependency of podman. I plan to maintain it as part of the
pkg-golang team umbrella

Bug#1054273: ITP: golang-github-checkpoint-restore-checkpointctl -- Tool to inspect Kubernetes and Podman checkpoints

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-checkpoint-restore-checkpointctl
  Version : 1.1.0-1
  Upstream Author : 
* URL : https://github.com/checkpoint-restore/checkpointctl
* License : Apache-2.0
  Programming Lang: Go
  Description : Tool to inspect Kubernetes and Podman checkpoints

 Container engines like *Podman* and *CRI-O* have the ability to
 checkpoint a container.  All data related to a checkpoint is collected
 in a checkpoint archive. With the help of this tool, checkpointctl, it
 is possible to display information about these checkpoint archives.

This is a dependency of podman. I plan to maintain it as part of the
pkg-golang team umbrella

Bug#1054273: ITP: golang-github-checkpoint-restore-checkpointctl -- Tool to inspect Kubernetes and Podman checkpoints

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-checkpoint-restore-checkpointctl
  Version : 1.1.0-1
  Upstream Author : 
* URL : https://github.com/checkpoint-restore/checkpointctl
* License : Apache-2.0
  Programming Lang: Go
  Description : Tool to inspect Kubernetes and Podman checkpoints

 Container engines like *Podman* and *CRI-O* have the ability to
 checkpoint a container.  All data related to a checkpoint is collected
 in a checkpoint archive. With the help of this tool, checkpointctl, it
 is possible to display information about these checkpoint archives.

This is a dependency of podman. I plan to maintain it as part of the
pkg-golang team umbrella

Bug#1054271: ITP: golang-github-coreos-stream-metadata-go -- Go library for parsing Fedora CoreOS streams

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-coreos-stream-metadata-go
  Version : 0.4.3-1
  Upstream Author : CoreOS
* URL : https://github.com/coreos/stream-metadata-go
* License : Apache-2.0
  Programming Lang: Go
  Description : Go library for parsing Fedora CoreOS streams

 Go library for parsing Fedora CoreOS streams
 .
 See the Fedora CoreOS documentation (https://docs.fedoraproject.org/en-
 US/fedora-coreos/getting-started/) for basic information about streams.
 .
 This is a Go library which exposes API to decode streams into Go
 structs, as well as a convenience API to find the URL for a given
 stream.


This package is used by podman machine. I plan to maintain it under the
pkg-golang team umbrella

Bug#1054271: ITP: golang-github-coreos-stream-metadata-go -- Go library for parsing Fedora CoreOS streams

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-coreos-stream-metadata-go
  Version : 0.4.3-1
  Upstream Author : CoreOS
* URL : https://github.com/coreos/stream-metadata-go
* License : Apache-2.0
  Programming Lang: Go
  Description : Go library for parsing Fedora CoreOS streams

 Go library for parsing Fedora CoreOS streams
 .
 See the Fedora CoreOS documentation (https://docs.fedoraproject.org/en-
 US/fedora-coreos/getting-started/) for basic information about streams.
 .
 This is a Go library which exposes API to decode streams into Go
 structs, as well as a convenience API to find the URL for a given
 stream.


This package is used by podman machine. I plan to maintain it under the
pkg-golang team umbrella

Bug#1054271: ITP: golang-github-coreos-stream-metadata-go -- Go library for parsing Fedora CoreOS streams

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-coreos-stream-metadata-go
  Version : 0.4.3-1
  Upstream Author : CoreOS
* URL : https://github.com/coreos/stream-metadata-go
* License : Apache-2.0
  Programming Lang: Go
  Description : Go library for parsing Fedora CoreOS streams

 Go library for parsing Fedora CoreOS streams
 .
 See the Fedora CoreOS documentation (https://docs.fedoraproject.org/en-
 US/fedora-coreos/getting-started/) for basic information about streams.
 .
 This is a Go library which exposes API to decode streams into Go
 structs, as well as a convenience API to find the URL for a given
 stream.


This package is used by podman machine. I plan to maintain it under the
pkg-golang team umbrella

Bug#1054271: ITP: golang-github-coreos-stream-metadata-go -- Go library for parsing Fedora CoreOS streams

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-coreos-stream-metadata-go
  Version : 0.4.3-1
  Upstream Author : CoreOS
* URL : https://github.com/coreos/stream-metadata-go
* License : Apache-2.0
  Programming Lang: Go
  Description : Go library for parsing Fedora CoreOS streams

 Go library for parsing Fedora CoreOS streams
 .
 See the Fedora CoreOS documentation (https://docs.fedoraproject.org/en-
 US/fedora-coreos/getting-started/) for basic information about streams.
 .
 This is a Go library which exposes API to decode streams into Go
 structs, as well as a convenience API to find the URL for a given
 stream.


This package is used by podman machine. I plan to maintain it under the
pkg-golang team umbrella

Bug#1053131: Status Update

[Reinhard Tartler]

I've started packaging all dependencies up to buildah and have updated the
repository for 4.7.1 in the branch debian/experimental, commit e71d62879

Here is where I'm currently at:

src/github.com/containers/podman/pkg/machine/fcos.go:17:2: cannot find package 
"github.com/coreos/stream-metadata-go/fedoracoreos" in any of:
/usr/lib/go-1.21/src/github.com/coreos/stream-metadata-go/fedoracoreos 
(from $GOROOT)

/<>/_output/src/github.com/coreos/stream-metadata-go/fedoracoreos 
(from $GOPATH)
src/github.com/containers/podman/pkg/machine/fcos.go:18:2: cannot find package 
"github.com/coreos/stream-metadata-go/release" in any of:
/usr/lib/go-1.21/src/github.com/coreos/stream-metadata-go/release (from 
$GOROOT)

/<>/_output/src/github.com/coreos/stream-metadata-go/release (from 
$GOPATH)
src/github.com/containers/podman/pkg/machine/fcos.go:19:2: cannot find package 
"github.com/coreos/stream-metadata-go/stream" in any of:
/usr/lib/go-1.21/src/github.com/coreos/stream-metadata-go/stream (from 
$GOROOT)

/<>/_output/src/github.com/coreos/stream-metadata-go/stream (from 
$GOPATH)
src/github.com/containers/podman/pkg/checkpoint/crutils/checkpoint_restore_utils.go:12:2:
 cannot find package "github.com/checkpoint-restore/checkpointctl/lib" in any 
of:
/usr/lib/go-1.21/src/github.com/checkpoint-restore/checkpointctl/lib 
(from $GOROOT)

/<>/_output/src/github.com/checkpoint-restore/checkpointctl/lib 
(from $GOPATH)
src/github.com/containers/podman/libpod/plugin/volume_api.go:19:2: cannot find 
package "github.com/docker/go-plugins-helpers/sdk" in any of:
/usr/lib/go-1.21/src/github.com/docker/go-plugins-helpers/sdk (from 
$GOROOT)
/<>/_output/src/github.com/docker/go-plugins-helpers/sdk 
(from $GOPATH)
src/github.com/containers/podman/libpod/plugin/volume_api.go:20:2: cannot find 
package "github.com/docker/go-plugins-helpers/volume" in any of:
/usr/lib/go-1.21/src/github.com/docker/go-plugins-helpers/volume (from 
$GOROOT)

/<>/_output/src/github.com/docker/go-plugins-helpers/volume (from 
$GOPATH)
package github.com/containers/podman/pkg/checkpoint: build constraints exclude 
all Go files in 
/<>/_output/src/github.com/containers/podman/pkg/checkpoint
package github.com/containers/podman/pkg/specgen/generate: build constraints 
exclude all Go files in 
/<>/_output/src/github.com/containers/podman/pkg/specgen/generate
package github.com/containers/podman/pkg/specgen/generate/kube: build 
constraints exclude all Go files in 
/<>/_output/src/github.com/containers/podman/pkg/specgen/generate/kube
src/github.com/containers/podman/pkg/domain/infra/abi/play.go:41:2: cannot find 
package "k8s.io/kubernetes/third_party/forked/golang/expansion" in any of:

/usr/lib/go-1.21/src/k8s.io/kubernetes/third_party/forked/golang/expansion 
(from $GOROOT)

/<>/_output/src/k8s.io/kubernetes/third_party/forked/golang/expansion
 (from $GOPATH)


I'm not really sure what changed from the previous version, but this needs ot
be resolved one way or another. Please reach out to me if you are interested in
helping out here.

-rt

[pkg-go] Bug#1053131: Status Update

[Reinhard Tartler]

I've started packaging all dependencies up to buildah and have updated the
repository for 4.7.1 in the branch debian/experimental, commit e71d62879

Here is where I'm currently at:

src/github.com/containers/podman/pkg/machine/fcos.go:17:2: cannot find package 
"github.com/coreos/stream-metadata-go/fedoracoreos" in any of:
/usr/lib/go-1.21/src/github.com/coreos/stream-metadata-go/fedoracoreos 
(from $GOROOT)

/<>/_output/src/github.com/coreos/stream-metadata-go/fedoracoreos 
(from $GOPATH)
src/github.com/containers/podman/pkg/machine/fcos.go:18:2: cannot find package 
"github.com/coreos/stream-metadata-go/release" in any of:
/usr/lib/go-1.21/src/github.com/coreos/stream-metadata-go/release (from 
$GOROOT)

/<>/_output/src/github.com/coreos/stream-metadata-go/release (from 
$GOPATH)
src/github.com/containers/podman/pkg/machine/fcos.go:19:2: cannot find package 
"github.com/coreos/stream-metadata-go/stream" in any of:
/usr/lib/go-1.21/src/github.com/coreos/stream-metadata-go/stream (from 
$GOROOT)

/<>/_output/src/github.com/coreos/stream-metadata-go/stream (from 
$GOPATH)
src/github.com/containers/podman/pkg/checkpoint/crutils/checkpoint_restore_utils.go:12:2:
 cannot find package "github.com/checkpoint-restore/checkpointctl/lib" in any 
of:
/usr/lib/go-1.21/src/github.com/checkpoint-restore/checkpointctl/lib 
(from $GOROOT)

/<>/_output/src/github.com/checkpoint-restore/checkpointctl/lib 
(from $GOPATH)
src/github.com/containers/podman/libpod/plugin/volume_api.go:19:2: cannot find 
package "github.com/docker/go-plugins-helpers/sdk" in any of:
/usr/lib/go-1.21/src/github.com/docker/go-plugins-helpers/sdk (from 
$GOROOT)
/<>/_output/src/github.com/docker/go-plugins-helpers/sdk 
(from $GOPATH)
src/github.com/containers/podman/libpod/plugin/volume_api.go:20:2: cannot find 
package "github.com/docker/go-plugins-helpers/volume" in any of:
/usr/lib/go-1.21/src/github.com/docker/go-plugins-helpers/volume (from 
$GOROOT)

/<>/_output/src/github.com/docker/go-plugins-helpers/volume (from 
$GOPATH)
package github.com/containers/podman/pkg/checkpoint: build constraints exclude 
all Go files in 
/<>/_output/src/github.com/containers/podman/pkg/checkpoint
package github.com/containers/podman/pkg/specgen/generate: build constraints 
exclude all Go files in 
/<>/_output/src/github.com/containers/podman/pkg/specgen/generate
package github.com/containers/podman/pkg/specgen/generate/kube: build 
constraints exclude all Go files in 
/<>/_output/src/github.com/containers/podman/pkg/specgen/generate/kube
src/github.com/containers/podman/pkg/domain/infra/abi/play.go:41:2: cannot find 
package "k8s.io/kubernetes/third_party/forked/golang/expansion" in any of:

/usr/lib/go-1.21/src/k8s.io/kubernetes/third_party/forked/golang/expansion 
(from $GOROOT)

/<>/_output/src/k8s.io/kubernetes/third_party/forked/golang/expansion
 (from $GOPATH)


I'm not really sure what changed from the previous version, but this needs ot
be resolved one way or another. Please reach out to me if you are interested in
helping out here.

-rt

___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-go-maintainers

Re: Updating golang-github-checkpoint-restore-go-criu to v6

[Reinhard Tartler]

On Thu, Oct 12, 2023 at 11:04 PM Mathias Gibbens  wrote:

> [...] the
> upstream main branch has switched to v6. Attempting to patch runc to
> use v6 in Debian seems too invasive, and I don't know how long it will
> be until runc releases a version that uses v6.
>

Looking ta
https://github.com/opencontainers/runc/commit/fbce47a6b67bad0da33ea9c17a4ade0ccd89d6cd
it seems that the bulk of the diff is part of the vendor/ directory, which
we would ignore for a debian patch anyways. The actual patch appears to be
touching only import lines in 3 .go files of the upstream source. I must be
missing something because that doesn't look invasive at all. Can you
elaborate on why you feel that's not a good approach?

On a side note, I'd love to see
getting golang-github-checkpoint-restore-go-criu upgraded to v6 soon. This
would allow me to stop patching libpod to downgrade to v5, cf.
https://salsa.debian.org/debian/libpod/-/blob/debian/sid/debian/patches/downgrade-checkpoint-restore-criu.patch

Thanks!


-- 
regards,
Reinhard

Bug#1053589: RFP: rust-matchit -- high performance, zero-copy URL router

[Reinhard Tartler]

Indeed, allow prerelease does seem to help. Debcargo still produces the same 
message but carries on with generating the package

Thanks 

On October 8, 2023 9:41:44 AM EDT, Jonas Smedegaard  wrote:
>Quoting Reinhard Tartler (2023-10-08 15:24:26)
>> On 10/7/23 2:25 AM, Jonas Smedegaard wrote:
>> > Package: wnpp
>> > Severity: wishlist
>> > X-Debbugs-Cc: Reinhard Tartler 
>> > 
>> > * Package name: rust-matchit
>> >Version : 0.7.3
>> >Upstream Contact: Ibraheem Ahmed 
>> > * URL : https://github.com/ibraheemdev/matchit
>> > * License : BSD-3-Clause and Expat
>> >Programming Lang: Rust
>> >Description : high performance, zero-copy URL router
>> > 
>> >   matchit is a high performance, zero-copy URL router,
>> >   taking advantage of the fact
>> >   that URL routes generally follow a hierarchical structure,
>> >   allowing to reduce the route search to a small number of branches.
>> > 
>> > This package is needed for rust-axum (bug#1052404).
>> > 
>> 
>> while trying to package this with debcargo, I'm seeing this error message:
>> 
>> $ REALVER=0.7.3 ./update.sh matchit
>>  Updating crates.io index
>> debcargo failed: Cannot represent prerelease part of dependency: gonzales 
>> Comparator { op: Caret, major: 0, minor: Some(0), patch: Some(3), pre: 
>> Prerelease("beta") }
>> Command failed. If the patches failed to apply, to rebase them, run:
>> cd /srv/scratch/packages/rust/debcargo-conf/build/matchit
>> quilt pop -a -f
>> rm -rf .pc
>> ln -s /srv/scratch/packages/rust/debcargo-conf/src/matchit/debian/patches
>> quilt push --fuzz=0 -a -f
>> emacsclient 
>> quilt refresh
>> 
>> I guess this is because of this line:
>> 
>> https://github.com/ibraheemdev/matchit/blob/64af4bd02757c7d12412d871c3143b18de60e9df/Cargo.toml#L21
>> 
>> gonzales = "0.0.3-beta"
>> 
>> 
>> How to package this? Does 'debcargo' need a fix?
>
>It seems from the error message that debcargo is well aware of its
>inability to handle crates containing a prerelease component.
>
>It seems from notes in source that you can gamble and hope for the best
>by somehow setting some "allow_prerelease_deps" flag:
>https://sources.debian.org/src/rust-debcargo/2.6.0-3/src/debian/dependency.rs/?hl=187#L187
>
>
> - Jonas
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#1053589: RFP: rust-matchit -- high performance, zero-copy URL router

[Reinhard Tartler]

Indeed, allow prerelease does seem to help. Debcargo still produces the same 
message but carries on with generating the package

Thanks 

On October 8, 2023 9:41:44 AM EDT, Jonas Smedegaard  wrote:
>Quoting Reinhard Tartler (2023-10-08 15:24:26)
>> On 10/7/23 2:25 AM, Jonas Smedegaard wrote:
>> > Package: wnpp
>> > Severity: wishlist
>> > X-Debbugs-Cc: Reinhard Tartler 
>> > 
>> > * Package name: rust-matchit
>> >Version : 0.7.3
>> >Upstream Contact: Ibraheem Ahmed 
>> > * URL : https://github.com/ibraheemdev/matchit
>> > * License : BSD-3-Clause and Expat
>> >Programming Lang: Rust
>> >Description : high performance, zero-copy URL router
>> > 
>> >   matchit is a high performance, zero-copy URL router,
>> >   taking advantage of the fact
>> >   that URL routes generally follow a hierarchical structure,
>> >   allowing to reduce the route search to a small number of branches.
>> > 
>> > This package is needed for rust-axum (bug#1052404).
>> > 
>> 
>> while trying to package this with debcargo, I'm seeing this error message:
>> 
>> $ REALVER=0.7.3 ./update.sh matchit
>>  Updating crates.io index
>> debcargo failed: Cannot represent prerelease part of dependency: gonzales 
>> Comparator { op: Caret, major: 0, minor: Some(0), patch: Some(3), pre: 
>> Prerelease("beta") }
>> Command failed. If the patches failed to apply, to rebase them, run:
>> cd /srv/scratch/packages/rust/debcargo-conf/build/matchit
>> quilt pop -a -f
>> rm -rf .pc
>> ln -s /srv/scratch/packages/rust/debcargo-conf/src/matchit/debian/patches
>> quilt push --fuzz=0 -a -f
>> emacsclient 
>> quilt refresh
>> 
>> I guess this is because of this line:
>> 
>> https://github.com/ibraheemdev/matchit/blob/64af4bd02757c7d12412d871c3143b18de60e9df/Cargo.toml#L21
>> 
>> gonzales = "0.0.3-beta"
>> 
>> 
>> How to package this? Does 'debcargo' need a fix?
>
>It seems from the error message that debcargo is well aware of its
>inability to handle crates containing a prerelease component.
>
>It seems from notes in source that you can gamble and hope for the best
>by somehow setting some "allow_prerelease_deps" flag:
>https://sources.debian.org/src/rust-debcargo/2.6.0-3/src/debian/dependency.rs/?hl=187#L187
>
>
> - Jonas
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#1053589: RFP: rust-matchit -- high performance, zero-copy URL router

[Reinhard Tartler]

On 10/7/23 2:25 AM, Jonas Smedegaard wrote:

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: Reinhard Tartler 

* Package name: rust-matchit
   Version : 0.7.3
   Upstream Contact: Ibraheem Ahmed 
* URL : https://github.com/ibraheemdev/matchit
* License : BSD-3-Clause and Expat
   Programming Lang: Rust
   Description : high performance, zero-copy URL router

  matchit is a high performance, zero-copy URL router,
  taking advantage of the fact
  that URL routes generally follow a hierarchical structure,
  allowing to reduce the route search to a small number of branches.

This package is needed for rust-axum (bug#1052404).



while trying to package this with debcargo, I'm seeing this error message:

$ REALVER=0.7.3 ./update.sh matchit
Updating crates.io index
debcargo failed: Cannot represent prerelease part of dependency: gonzales Comparator { 
op: Caret, major: 0, minor: Some(0), patch: Some(3), pre: Prerelease("beta") }
Command failed. If the patches failed to apply, to rebase them, run:
cd /srv/scratch/packages/rust/debcargo-conf/build/matchit
quilt pop -a -f
rm -rf .pc
ln -s /srv/scratch/packages/rust/debcargo-conf/src/matchit/debian/patches
quilt push --fuzz=0 -a -f
emacsclient 
quilt refresh

I guess this is because of this line:

https://github.com/ibraheemdev/matchit/blob/64af4bd02757c7d12412d871c3143b18de60e9df/Cargo.toml#L21

gonzales = "0.0.3-beta"


How to package this? Does 'debcargo' need a fix?

-rt

Bug#1053589: RFP: rust-matchit -- high performance, zero-copy URL router

[Reinhard Tartler]

On 10/7/23 2:25 AM, Jonas Smedegaard wrote:

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: Reinhard Tartler 

* Package name: rust-matchit
   Version : 0.7.3
   Upstream Contact: Ibraheem Ahmed 
* URL : https://github.com/ibraheemdev/matchit
* License : BSD-3-Clause and Expat
   Programming Lang: Rust
   Description : high performance, zero-copy URL router

  matchit is a high performance, zero-copy URL router,
  taking advantage of the fact
  that URL routes generally follow a hierarchical structure,
  allowing to reduce the route search to a small number of branches.

This package is needed for rust-axum (bug#1052404).



while trying to package this with debcargo, I'm seeing this error message:

$ REALVER=0.7.3 ./update.sh matchit
Updating crates.io index
debcargo failed: Cannot represent prerelease part of dependency: gonzales Comparator { 
op: Caret, major: 0, minor: Some(0), patch: Some(3), pre: Prerelease("beta") }
Command failed. If the patches failed to apply, to rebase them, run:
cd /srv/scratch/packages/rust/debcargo-conf/build/matchit
quilt pop -a -f
rm -rf .pc
ln -s /srv/scratch/packages/rust/debcargo-conf/src/matchit/debian/patches
quilt push --fuzz=0 -a -f
emacsclient 
quilt refresh

I guess this is because of this line:

https://github.com/ibraheemdev/matchit/blob/64af4bd02757c7d12412d871c3143b18de60e9df/Cargo.toml#L21

gonzales = "0.0.3-beta"


How to package this? Does 'debcargo' need a fix?

-rt

Bug#1031097: bullseye-pu: package conmon/2.0.25+ds1-1.1

[Reinhard Tartler]

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#1014030: Bug#1031097: bullseye-pu: package conmon/2.0.25+ds1-1.1

[Reinhard Tartler]

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#1052431: RFP: rust-tonic -- rust implementation of gRPC

[Reinhard Tartler]

I believe all dependencies are now in sid:

- https://tracker.debian.org/pkg/rust-prettyplease
- https://tracker.debian.org/pkg/rust-hyper-timeout

anything else that is missing?

-rt

On 9/25/23 8:12 AM, Reinhard Tartler wrote:



On 9/22/23 1:42 PM, Jonas Smedegaard wrote:

Quoting Reinhard Tartler (2023-09-22 13:09:08)

How about I take care of hyper-timeout and prettyplease in debcargo-conf
(i.e., the rust team mass-packaging repo), and try to assist you with packaging
the workspace builds of tonic (which includes tonic-build, cf. 
https://github.com/hyperium/tonic/tree/master/tonic-build)
and axum?


Deal! :-)


hyper-timeout: https://ftp-master.debian.org/new/rust-hyper-timeout_0.4.1-1.html
prettyplease: https://tracker.debian.org/pkg/rust-prettyplease

both versions currently in the archive should satisfy requirements for tonic.

Let me know what other dependencies are missing, happy to add them to 
debcargo-conf.git

-rt