Bug#1070411: containerd fails to build as a normal user due to sysctl

[Reinhard Tartler]

Jochen Sprickerhof  writes:

> containerd uses sysctl during the build which fails as a normal user:
>
> === RUN   TestLinuxSandboxContainerSpec
> sandbox_run_linux_test.go:241: TestCase "spec should reflect original 
> config"
> sandbox_run_linux_test.go:71: Check PodSandbox annotations
> sandbox_run_linux_test.go:124:
> Error Trace:
> /<>/_build/src/github.com/containerd/containerd/pkg/cri/server/sandbox_run_linux_test.go:124
> 
> /<>/_build/src/github.com/containerd/containerd/pkg/cri/server/sandbox_run_linux_test.go:259
> Error:  "" does not contain "0 2147483647"
> Test:   TestLinuxSandboxContainerSpec
> sandbox_run_linux_test.go:241: TestCase "host namespace"
> sandbox_run_linux_test.go:71: Check PodSandbox annotations
> sandbox_run_linux_test.go:241: TestCase "should set supplemental groups 
> correctly"
> sandbox_run_linux_test.go:71: Check PodSandbox annotations
> sandbox_run_linux_test.go:241: TestCase "should overwrite default sysctls"
> sandbox_run_linux_test.go:71: Check PodSandbox annotations
> sandbox_run_linux_test.go:241: TestCase "sandbox sizing annotations 
> should be set if LinuxContainerResources were provided"
> sandbox_run_linux_test.go:71: Check PodSandbox annotations
> sandbox_run_linux_test.go:241: TestCase "sandbox sizing annotations 
> should not be set if LinuxContainerResources were not provided"
> sandbox_run_linux_test.go:71: Check PodSandbox annotations
> sandbox_run_linux_test.go:241: TestCase "sandbox sizing annotations are 
> zero if the resources are set to 0"
> sandbox_run_linux_test.go:71: Check PodSandbox annotations
> --- FAIL: TestLinuxSandboxContainerSpec (0.00s)
>
> https://salsa.debian.org/go-team/packages/containerd/-/blob/debian/sid/pkg/cri/server/sandbox_run_linux_test.go#L124

Are you sure that the test is actually executing a sysctl(2) command?
Looking at the code, it seems to me that this is code is assembling a
runtime spec that the CRI implementation will then carry out.
Forthermore, the output above indicates that the assertion on line 123
actually holds, but the one on line 124 does not:

https://sources.debian.org/src/containerd/1.6.24~ds1-1/pkg/cri/server/sandbox_run_linux_test.go/#L124

The cause for this is most likely in 
https://sources.debian.org/src/containerd/1.6.24~ds1-1/pkg/cri/server/sandbox_run_linux.go/#L147.
 Here the code is explicitly checking whether it is running in in a 
usernamespace, which is exactly what 'unshare' is doing.

> This make the build fail for example in the sbuild unshare backend.

Well, technically the build of the code succeeds, but the tests don't
run in a usernamespace.

Arguably, the test could be updated to skip this assertion if running in
a user namespace.

Can you please help me understand whether, and if so since when, we have
the requirement that all packages must be buildable inside a
usernamespace and where was this announced to be release-critical?
(CC'ed debian-release for input).

I'm inclined to downgrade this bug to severity "normal" or "wishlist".

If that really needs to be fixed, I could imagine to either disable the
test, or change the test to skip that assertion if running inside a user
namespace.

I would recommend forwarding this as a bug to upsream to see how relevant
running the containerd testsuite is in a user namespace. This feels like
a rather fringe/niche use-case anyways.

Best,
-rt

Bug#1033839: Packaging docker 24.0.9

[Reinhard Tartler]

Adding debian-go@, I think this topic deserves a wider audience

On Mon, Jun 3, 2024 at 2:31 PM Reinhard Tartler  wrote:

> Basically notary insists on golang-github-golang-protobuf-1-3-dev,
> whereas golang-github-grpc-ecosystem-grpc-gateway.v2-dev (which is coming
> via the opentelemetry deps) is expecting
> golang-github-golang-protobuf-1-5-dev.
>
> How can we resolve this situation?
>

so, I noticed that we have at least 12 packages in Debian that have
alternative dependency declaration in the form of
`golang-github-golang-protobuf-1-3-dev |
golang-github-golang-protobuf-1-5-dev`. Most (if not all of them) contain
generated *.pb.go files. I think I may have been under the false assumption
that code generated with protoc-gen-go-1-3 would not be compatible
with golang-github-golang-protobuf-1-5-dev. But is code generated with
protoc-gen-go-1-5 actually compatible with
golang-github-golang-protobuf-1-3-dev, that is, can it be linked with
golang/protobuf @v1.3?

However, in that case the alternative "Depends" on those 12+ packages still
confuses me. Let me explain.

As far as I can tell, there are several implementations of protobuf, each
coming with their own code generator and runtime library. Let me put this
down the four implementations of protobuf in Debian in the following table:

source package| generator | notes

--| - | -

golang-gogoprotobuf   | gogoprotobuf  | more performant,
deprecated upstream
golang-github-golang-protobuf-1-3 | protoc-gen-go-1-3 | implements protobuf
APIv1
golang-github-golang-protobuf-1-5 | protoc-gen-go-1-5 | is a version of
APIv1 implemented "in terms of APIv2"
golang-google-protobuf| protoc-gen-go | APIv2, supersedes
the above

The above information is mostly taken out of my understanding from
https://go.dev/blog/protobuf-apiv2

The alternative dependencies in the 12+ package seem to imply that the
generated code in those packages can be freely used with the runtimes that
come with either golang/protobuf@v1.3 or @v1.5. But is that actually a safe
assumption? I'm particularly concerned that code generated with
protoc-gen-go-1-5 is unlikely to work with the library that comes with
golang-github-golang-protobuf-1-3. I can see the other way around (code
generated with protoc-gen-go-1-3 working with golang/protobuf@v1.3), but
that sounds like something we should set a policy for.

I totally see how code generated with gogoprotobuf not being compatible
with anything else, leading to issues such as #975431 /
https://github.com/containerd/ttrpc/issues/62#issuecomment-686768932. So
this is effectively prevented by the "Conflicts" relationship
in golang-github-golang-protobuf-1-5-dev:

Package: golang-github-golang-protobuf-1-5-dev
Source: golang-github-golang-protobuf-1-5
Version: 1.5.4-1
Conflicts: golang-github-golang-protobuf-1-3-dev, golang-goprotobuf-dev

Similarly, we have another relationship here:

Package: golang-github-golang-protobuf-1-3-dev
Source: golang-github-golang-protobuf-1-3
Version: 1.3.5-4
Conflicts: golang-github-golang-protobuf-1-5-dev

(Isn't there a missing Conflicts relationship on golang-goprotobuf-dev? --
is that intentional or an oversight?)

In a similar vein, I can see that code generated by protoc-gen-go might
cause similar crashes when used with the runtime from
golang-github-golang-protobuf-1-3 (or possibly
golang-github-golang-protobuf-1-5, but I'm not sure). Note that neither
package declares any conflicts to golang-google-protobuf-dev (which comes
from google/protobuf). Is that intentional or an oversight?


Does my rambling above make sense? What conclusions do we want to take from
here?

 - It seems to me that we probably want to move packages away from
src:golang-gogoprotobuf as much as possible, in particular because of the
interoperability concerns. Is that agreeable?

 - It also seems to me that we probably want to avoid having both
golang-github-golang-protobuf-1-3 and golang-github-golang-protobuf-1-5 at
the same time. Both implement APIv1, and as such should be source-code
compatible. We currently seem to have 19 packages build-depending
on golang-github-golang-protobuf-1-3-dev. Can we lift-and-shift all of them
in one transition to @v1.5?

- As for packaging docker 2.4 (cf. #1033839, which spun off this
conversation), which of the four library implementations above should it be
linking against? -- We can savely rule out gogoprotobuf (it's deprecated),
and I guess google-protobuf as well, because I don't think all dependencies
have moved to the APIv2. That leaves two options: golang-protobuf @v1.3 and
@v1.5. Given the compatibility concerns above, I guess @v1.5 is the better
choice. That means that at least the 'notary' package needs to be updated
(as Arnaud points separately) to pick up protobuf v1.5.

- Currently, packages that use grpc (that is, build-depend
on  golang-g

Bug#1072503: RM: golang-github-google-cel-go-dev/experimental -- ROM; superseeded in unstable

[Reinhard Tartler]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: golang-github-google-cel...@packages.debian.org, 
debian...@lists.debian.org
Control: affects -1 + src:golang-github-google-cel-go
User: ftp.debian@packages.debian.org
Usertags: remove

I don't know what happened here, but somehow we ended up with a version higher
in unstable than experimental?

 $ rmadison golang-github-google-cel-go
golang-github-google-cel-go | 0.7.3+ds-3| experimental   | source
golang-github-google-cel-go | 0.7.3+ds-3| experimental-debug | source
golang-github-google-cel-go | 0.12.5+ds-1   | unstable   | source

That's very confusing. Can we please delete the outdated version in 
experimental please?

-rt

Bug#1072393: ITP: golang-github-go-jose-go-jose.v3 -- Implementation of JOSE standards (JWE, JWS, JWT) in Go (library) v3 branch

[Reinhard Tartler]

Package: wnpp
Owner: Reinhard Tartler 
Severity: wishlist

* Package name: golang-github-go-jose-go-jose.v3
  Version : 3.0.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 : Implementation of JOSE standards (JWE, JWS, JWT) in Go 
(library) v3 branch

I intend to re-upload go-jose v3 to sid

While upstream really prefers projects to move to the v4 branch, that
branch requires significant changes to applications. In Debian, we still
have a number of packages depending on the v2 branch, which is out of
maintenance. Moving them over to v3 is more expedient than waiting for
upstreams to port over to v4.


The two main changes from v3 to v4 are:
 - requires golang 1.21
 - accepted 'alg' and 'enc' values in incoming JWT/JWEs need to be specified. 
In v3,
   go-jose would accept all implemented algorithms, which can cause issues. 
Going forward,
   software needs to be explicit what they accept.

I came across this when looking at a CVE in buildah, noticing that
ocicrypt is currently using the v2 branch in debian (!), whereas
upstream is using the v4 branch. We currently have upgraded the package
to v4 earlier this year, and to get ocicrypt to build against that, this
might be required: https://github.com/containers/ocicrypt/pull/109

To avoid this for other packages, let's re-introduce .v3 for now and
part packages currently using .v2 over to .v4, and where difficult, at
least .v2 as interim step.

Bug#1072143: Depends: golang-github-labstack-echo.v3-dev but it is not installable

[Reinhard Tartler]

Package: golang-opentelemetry-contrib-dev
Version: 0.25.0-1
Severity: normal

$ apt install -s golang-opentelemetry-contrib-dev
NOTE: This is only a simulation!
  apt needs root privileges for real execution.
  Keep also in mind that locking is deactivated,
  so don't depend on the relevance to the real current situation!

Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

Unsatisfied dependencies:
 golang-opentelemetry-contrib-dev : Depends: golang-github-labstack-echo.v3-dev 
but it is not installable



-- 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)
Kernel taint flags: TAINT_WARN
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 golang-opentelemetry-contrib-dev depends on:
pn  golang-github-aws-aws-sdk-go-dev
pn  golang-github-aws-smithy-go-dev 
pn  golang-github-bradfitz-gomemcache-dev   
pn  golang-github-datadog-datadog-go-dev
pn  golang-github-felixge-fgprof-dev
pn  golang-github-felixge-httpsnoop-dev 
pn  golang-github-gin-gonic-gin-dev 
pn  golang-github-go-kit-kit-dev
pn  golang-github-gocql-gocql-dev   
pn  golang-github-gorilla-mux-dev   
pn  golang-github-labstack-echo-dev 
pn  golang-github-labstack-echo.v3-dev  
pn  golang-github-openshift-api-dev 
pn  golang-github-prometheus-client-golang-dev  
pn  golang-github-shirou-gopsutil-dev   
pn  golang-github-spf13-viper-dev   
pn  golang-gopkg-macaron.v1-dev 
pn  golang-mongodb-mongo-driver-dev 
pn  golang-opentelemetry-otel-dev   

golang-opentelemetry-contrib-dev recommends no packages.

golang-opentelemetry-contrib-dev suggests no packages.

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#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#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#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

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]

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]

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#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

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

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#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

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#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.

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

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#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#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#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#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#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

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#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

Bug#1053131: Fwd: [containers/podman] Release v4.7.0 - v4.7.0

[Reinhard Tartler]

Package: libpod
severity: wishlist

-- Forwarded message -
From: Lokesh Mandvekar 
Date: Wed, Sep 27, 2023 at 2:02 PM
Subject: [containers/podman] Release v4.7.0 - v4.7.0
To: containers/podman 
Cc: Subscribed 


v4.7.0 

Repository: containers/podman  · Tag:
v4.7.0  · Commit: 073183f

· Released by: lsm5 
Security

   - Now the io.containers.capabilities LABEL in an image can be an empty
   string.

Features

   - New command set: podman farm [create,list,remove,update] has been
   created to "farm" out builds to machines running Podman for different
   architectures.
   - New command: podman compose as a thin wrapper around an external
   compose provider such as docker-compose or podman-compose.
   - FreeBSD: podman run --device is now supported.
   - Linux: Add a new --module flag for Podman.
   - Podmansh: Timeout is now configurable using the podmansh_timeout
   option in containers.conf.
   - SELinux: Add support for confined users to create containers but
   restrict them from creating privileged containers.
   - WSL: Registers shared socket bindings on Windows, to allow other WSL
   distributions easy remote access (#15190
   ).
   - WSL: Enabling user-mode-networking on older WSL2 generations will now
   detect an error with upgrade guidance.
   - The podman build command now supports two new options: --layer-label
   and --cw.
   - The podman kube generate command now supports generation of k8s
   DaemonSet kind (#18899
   ).
   - The podman kube generate and podman kube play commands now support the
   k8s TerminationGracePeriodSeconds field (RH BZ#2218061
   ).
   - The podman kube generate and podman kube play commands now
support securityContext.procMount:
   Unmasked (#19881 ).
   - The podman generate kube command now supports a --podman-only flag to
   allow podman-only reserved annotations to be used in the generated YAML
   file. These annotations cannot be used by Kubernetes.
   - The podman kube generate now supports a --no-trunc flag that supports
   YAML files with annotations longer than 63 characters. Warning: if an
   annotation is longer than 63 chars, then the generated yaml file is not
   Kubernetes compatible.
   - An infra name annotation io.podman.annotations.infra.name is added in
   the generated yaml when the pod create command has --infra-name set.
   This annotation can also be used with kube play when wanting to
   customize the infra container name (#18312
   ).
   - The syntax of --uidmap and --gidmap has been extended to lookup the
   parent user namespace and to extend default mappings (#18333
   ).
   - The podman kube commands now support the List kind (#19052
   ).
   - The podman kube play command now supports environment variables in
   kube.yaml (#15983 ).
   - The podman push and podman manifest push commands now support the
   --force-compression optionto prevent reusing other blobs (#18860
   ).
   - The podman manifest push command now supports --add-compression to
   push with compressed variants.
   - The podman manifest push command now honors the add_compression field
   from containers.conf if --add-compression is not set.
   - The podman run and podman create --mount commands now support the ramfs
   type (#19659 ).
   - When running under systemd (e.g., via Quadlet), Podman will extend the
   start timeout in 30 second steps up to a maximum of 5 minutes when pulling
   an image.
   - The --add-host option now accepts the special string host-gateway
   instead of an IP Address, which will be mapped to the host IP address.
   - The podman generate systemd command is deprecated. Use Quadlet for
   running containers and pods under systemd.
   - The podman secret rm command now supports an --ignore option.
   - The --env-file option now supports multiline variables (#18724
   ).
   - The --read-only-tmpfs flag now affects /dev and /dev/shm as well as
   /run, /tmp, /var/tmp (#12937
   ).
   - The Podman --mount option now supports bind mounts passed as globs.
   - The --mount option can now be specified in containers.conf using the
   mounts field.
   - The podman stats now has an 

Bug#1052431: RFP: rust-tonic -- rust implementation of gRPC

[Reinhard Tartler]

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

Bug#1052532: ITP: golang-github-containers-luksy -- offline encryption/decryption using LUKS formats

[Reinhard Tartler]

Package: wnpp
Owner: Reinhard Tartler 
Severity: wishlist

* Package name: golang-github-containers-luksy
  Version : git
* URL or Web page : https://github.com/containers/luksy 
* License : Apache2
  Description : offline encryption/decryption using LUKS formats

 luksy implements encryption and decryption using LUKSv1 and LUKSv2
 formats. Think of it as a clunkier cousin of gzip/bzip2/xz that doesn't
 actually produce smaller output than input, but it encrypts, and that's
 nice.
 .
 The main goal is to be able to encrypt/decrypt when we don't have access to
 the Linux device mapper.  Duplicating functions of cryptsetup that it can
 perform without accessing the Linux device mapper is not a priority.

Bug#1052531: ITP: golang-github-aead-serpent -- Serpent block cipher

[Reinhard Tartler]

Package: wnpp
Owner: Reinhard Tartler 
Severity: wishlist

* Package name: golang-github-aead-serpent
  Version : git
  Upstream Author : Andreas Auernhammer
* URL or Web page : https://github.com/aead/serpent
* License : Expat
  Description : Serpent block cipher

 Serpent is a symmetric key block cipher that was a finalist in the
 Advanced Encryption Standard (AES) contest, where it was ranked second
 to Rijndael. Serpent was designed by Ross Anderson, Eli Biham, and Lars
 Knudsen.

Bug#1052431: RFP: rust-tonic -- rust implementation of gRPC

[Reinhard Tartler]

On 9/22/23 2:52 AM, Jonas Smedegaard wrote:

Quoting Reinhard Tartler (2023-09-21 22:43:24)

Package: wnpp
Severity: wishlist

* Package name: rust-tonic
   Version : 0.9
* URL or Web page : https://github.com/hyperium/tonic
* License : MIT
   Description : rust implementation of gRPC


Hey folks, I need help packaging tonic.

This package requires axum, for which I've filed #1052404. Tonic is
needed by newer versions of netavark (which is the userspace network
stack for podman, the alternative to docker).


Can someone please give me a hand with getting tonic into Debian?


I also need tonic, for safe-network (bug#1008016).

Besides axum, also missing crates are (it seems) hyper-timeout,
prettyplease and tonic-build.

If I were to package tonic (either helping you or alone), I would
package the workspace of both tonic and tonic-build as a single source
package.  Beware, though, that the Rust team is not familiar with nor
approves of my approach to packaging Rust crates, so if you want team
collaboration rather than more-like-other-Debian-packages style, then
perhaps ask in the team and ignore me...



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?

Best,
-rt

Bug#1052432: netavark: Upgrade to version 1.6 or later

[Reinhard Tartler]

Package: netavark
Version: 1.4.0-4
Severity: normal
X-Debbugs-Cc: none, Reinhard Tartler 

It would be great to upgrade the package to newer upstream version. I
could really need a hand with packaging the necessary
dependencies. Let's use this bug for tracking what needs to be done.


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

Kernel: Linux 6.4.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 netavark depends on:
ii  libc6  2.37-8
ii  libgcc-s1  13.2.0-3

Versions of packages netavark recommends:
ii  aardvark-dns  1.4.0-5

netavark suggests no packages.

-- no debconf information

Bug#1052431: RFP: rust-tonic -- rust implementation of gRPC

[Reinhard Tartler]

Package: wnpp
Severity: wishlist

* Package name: rust-tonic
  Version : 0.9
* URL or Web page : https://github.com/hyperium/tonic
* License : MIT
  Description : rust implementation of gRPC


Hey folks, I need help packaging tonic.

This package requires axum, for which I've filed #1052404. Tonic is
needed by newer versions of netavark (which is the userspace network
stack for podman, the alternative to docker).


Can someone please give me a hand with getting tonic into Debian?

Thanks!

Bug#1052404: RFP: axum -- web application framework that focuses on ergonomics and modularity

[Reinhard Tartler]

Package: wnpp
Severity: wishlist

* Package name: axum
  Version : 0.8.0
* URL or Web page : https://github.com/tokio-rs/axum
* License : MIT
  Description : web application framework that focuses on ergonomics and 
modularity

Hey folks, I need help packaging axum.

This package is a new dependency of https://github.com/hyperium/tonic,
which is needed by newer versions of netavark (which is the userspace
network stack for podman, the alternative to docker)

I struggle with packaging this package because it consists of two crates
that depend on each other. Upstream uses a workspace build and publishes
all of them, that is, axum, axum-core and axum-macros at the same time.
Turns out that the debcargo-conf infrastructure is not suitable for
this.

Can someone please give me a hand with packaging these three crates so
that they are built from a single debian source package?

Thanks!

Bug#1034590: precedence of /etc/containers/storage.conf should higher than /usr/share/containers/storage.conf

[Reinhard Tartler]

Control: tag -1 upstream

Hi,

Thanks for taking the time to report this. It doesn't sound like a problem
that we could fix in the packaging, but needs some code changes.  For this,
I'd like to ask you a favor. Can you please check if this was reported
before at https://github.com/containers/podman/issues ? If not yet, please
report it as https://github.com/containers/podman/issues/new/choose

In any case, please report back with the upstream issue number so that we
can track progress on resolving it.


On Fri, Jul 14, 2023 at 5:39 PM 鐘翊修  wrote:

> So
>
> |   Before upgrade to 4.4.0+ds1-1 (4.3)  |4.4.0+
> /etc/containers/strorage.conf|   use btrfs |btrfs
> /usr/share/containers/storage.conf  |   use
> overlayfs | overlayfs
>
> 
>
> When use 4.3, podman takes /etc/containers/storage.conf, so the storage
> is btrfs.
> But after upgrade 4.4.0+ (at least when it was April).
> Podman takes values in /usr/share/containers/storage.conf instead of
> /etc/containers/strorage.conf (wrong behavior)
> So just get the following
>
> User-selected graph driver \"overlay\" overwritten by graph driver
> \"btrfs\" from database
>
> That is the observed error. But not expected error.
>
> The expected behavior is
>
> Podman follows man 5 containers-storage.conf.
> Prefer values from /etc/containers/storage.conf.
>
> After version upgrade from 4.3 to 4.4, no configuration required, no
> reset required.
>
>
> Faidon Liambotis 於 2023/7/15 02:02 寫道:
> > Control: tags -1 moreinfo
> >
> > On Wed, Apr 19, 2023 at 09:24:21AM +0800, 鐘翊修 wrote:
> >> following man 5 containers-storage.conf,
> >> when a system have both /etc/containers/storage.conf and
> /usr/share/containers/storage.conf
> >>
> >> the values in /etc/containers/storage.conf overwrite the value in
> /usr/share/containers/storage.conf
> >>
> >> But in 4.4.0+ds1-1. with both files, podman takes the config from
> /usr/share/containers/stroage.conf
> >>
> >> To reproduce this
> >>
> >> Create podman graph database on podman 4.3.1 with btrfs (config in
> /etc/containers/storage.conf)
> >>
> >> upgrade from 4.3.1 to 4.4.0
> >>
> >> run the following command
> >>
> >> sudo podman info
> >>
> >> expected error message
> >>
> >> User-selected graph driver \"overlay\" overwritten by graph driver
> \"btrfs\" from database
> > I'm not sure I follow. Could you elaborate on the exact steps you took?
> > Do you mean that you expected to get this error message but didn't, or
> > that you got that error message even though you shouldn't have?
> >
> > Are you aware that you need to run "podman system reset" before changing
> > storage.conf? See podman-system-reset(1).
> >
> > Thanks,
> > Faidon
>
>

-- 
regards,
Reinhard

Bug#1042090: podman: fails to start container with userns mapping

[Reinhard Tartler]

Control: tag -1 +upstream +moreinfo

Hi Hristo,

Thanks for taking the time to report this issue. In the meantime, podman
4.5 is now in debian/testing (and 4.6.2 in debian/experimental). Can you
please upgrade your package and give it another try? If you're right, you
shouldn't see this issue anymore. Please report back so that I can mark
this as fixed in the Debian bug tracker.

Best,
-rt

On Wed, Jul 26, 2023 at 10:51 AM Hristo Venev  wrote:

> Package: podman
> Version: 4.3.1+ds1-8+b1
> Severity: normal
> X-Debbugs-Cc: hri...@venev.name
>
> Dear Maintainer,
>
> When trying to run a container using podman (as root) with a uid/gid
> mapping specified via `--userns`, it fails to start:
>
> > # podman run --rm --userns
> auto:uidmapping=1000:1001:1,gidmapping=1000:1001:1 debian:12
> > ERRO[] Unmounting
> /var/lib/containers/storage/overlay/INSERT_ID_HERE/merged: invalid argument
> > Error: mounting storage for container INSERT_ANOTHER_ID_HERE: creating
> overlay mount to /var/lib/containers/storage/overlay/INSERT_ID_HERE/merged,
> mount_data="lowerdir=/var/lib/containers/storage/overlay/INSERT_ID_HERE/mapped/0/l/INSERT_SHORT_ID_HERE:/var/lib/containers/storage/overlay/INSERT_ID_HERE/mapped/0/l/diff1:/var/lib/containers/storage/overlay/INSERT_ID_HERE/mapped/0/l/INSERT_ANOTHER_SHORT_ID_HERE,upperdir=/var/lib/containers/storage/overlay/INSERT_ID_HERE/diff,workdir=/var/lib/containers/storage/overlay/INSERT_ID_HERE/work,,volatile":
> permission denied
>
> The following appears in the kernel log:
> > [TIME] overlayfs: failed to resolve
> '/var/lib/containers/storage/overlay/INSERT_ID_HERE/mapped/0/l/INSERT_SHORT_ID_HERE':
> -13
>
> The outcome is listed above. The expected outcome was that the container
> would start, with most IDs mapped from those delegated to the
> `containers` user, except uid/gid 1000 inside the container which
> correspond to 1001 outside.
>
> Running the container with just `--userns auto` works. However, then all
> files passed to the container via bind mounts would be owned by
> nobody:nogroup instead of 1000:1000.
>
> This seems similar to https://github.com/containers/podman/issues/18435,
> which was probably fixed in podman 4.5.0.
>
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.3.0-1-amd64 (SMP w/24 CPU threads; PREEMPT)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages podman depends on:
> ii  conmon   2.1.6+ds1-1
> ii  crun 1.8.5-1
> ii  golang-github-containers-common  0.50.1+ds1-4
> ii  libc62.37-6
> ii  libdevmapper1.02.1   2:1.02.185-2
> ii  libgpgme11   1.18.0-3+b1
> ii  libseccomp2  2.5.4-1+b3
> ii  libsubid41:4.13+dfsg1-1+b1
>
> Versions of packages podman recommends:
> pn  buildah   
> pn  catatonit | tini | dumb-init  
> pn  dbus-user-session 
> pn  fuse-overlayfs
> pn  slirp4netns   
> pn  uidmap
>
> Versions of packages podman suggests:
> pn  containers-storage  
> pn  docker-compose  
> ii  iptables1.8.9-2
>
> -- no debconf information
>
>

-- 
regards,
Reinhard

Bug#1037091: podman run fails because of missing ~/.config/docker/config.json

[Reinhard Tartler]

Control: tag -1 +moreinfo +unreproducible

Hi Felix,

thanks for taking the time to write a bug report to Debian. I'm sorry to
hear that podman does not work for you as you'd expect. It seems to me that
you may have an old, possibly modified installation of podman on your
system, and I'd expect you wouldn't see this if you installed podman from
Debian in a fresh VM or new laptop. If you were, I'd absolutely love to
hear about this.

In order to recover your system, can you please try the command

podman system reset -f

You can read upon it at https://manpages.debian.org/podman-system-reset

Please let me know if that fixes the issue or whether you had further
thoughts or ideas on this.

Best,
-rt


On Sun, Jun 4, 2023 at 8:57 AM Felix Stupp 
wrote:

> Package: podman
> Version: 4.3.1+ds1-8+b1
> Severity: important
>
>
> Dear maintainer,
>
> the current version of podman does not allow me to run any container due
> to the following error message:
> Error: stat /home/$USER/.config/docker/config.json: no such file or
> directory
>
> I can trigger this issue with a simple: podman run debian
> However, what container I try to run seems not to matter.
>
> The current version in experimental (4.4.0+ds1-1) is also not working on
> my machine.
>
> I cannot say which version introduced this issue as I do not use podman
> very often. To the best of my knowledge, the last time I used it, it
> worked fine and I do not know of any changes I introduced (beside
> updates) which could explain this issue.
>
> However, it still seems at least weird to me, that podman requires (not
> just reads optionally) a config file which is in Docker's config dir.
>
> I can append further debugging information if requested.
>
> Thanks
> Felix Stupp
>
>
> -- System Information:
> Debian Release: 12.0
>   APT prefers testing
>   APT policy: (550, 'testing'), (500, 'testing-security'), (500,
> 'stable-security'), (400, 'stable-updates'), (400, 'stable'), (350,
> 'oldstable-updates'), (350, 'oldstable'), (110, 'unstable'), (102,
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 6.1.0-9-amd64 (SMP w/12 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages podman depends on:
> ii  conmon   2.1.6+ds1-1
> ii  crun 1.8.1-1+b1
> ii  golang-github-containers-common  0.50.1+ds1-4
> ii  libc62.36-9
> ii  libdevmapper1.02.1   2:1.02.185-2
> ii  libgpgme11   1.18.0-3+b1
> ii  libseccomp2  2.5.4-1+b3
> ii  libsubid41:4.13+dfsg1-1+b1
> ii  runc 1.1.5+ds1-1+b1
>
> Versions of packages podman recommends:
> ii  buildah1.28.2+ds1-3+b1
> ii  dbus-user-session  1.14.6-1
> ii  fuse-overlayfs 1.10-1
> ii  slirp4netns1.2.0-1
> ii  tini   0.19.0-1
> ii  uidmap 1:4.13+dfsg1-1+b1
>
> Versions of packages podman suggests:
> ii  containers-storage  1.43.0+ds1-8
> ii  docker-compose  1.29.2-3
> ii  iptables1.8.9-2
>
> -- Configuration Files:
> /etc/cni/net.d/87-podman-bridge.conflist [Errno 13] Permission denied:
> '/etc/cni/net.d/87-podman-bridge.conflist'
>
> -- no debconf information
>
>

-- 
regards,
Reinhard

Bug#1050993: podman: Podman should use overlay storage driver by default instead of vfs

[Reinhard Tartler]

Hi Gregor,

On Wed, Sep 13, 2023 at 3:03 AM Gregor Riepl  wrote:

> As mentioned in the upstream bug report[1], the fix is actually in
> containers/storage 1.48, included with podman 4.6 and not 4.5.
>
> So, the bug can (hopefully) be fixed for good when this version is
> packaged.
>

I've now worked on packaging 4.6.2, and it is currently available
in debian/experimental. Can you do me a favor? Please test it and let me
know whether
it fixes this issue.



> It might also be helpful to include a what's new message, to make users
> aware they need to reset their storage after upgrading. There doesn't
> seem to be an easy way to convert vfs containers or images to overlay.
>
> [1]
> https://github.com/containers/podman/issues/19811#issuecomment-1716344802
>
> I'm happy to add a note in NEWS.Debian, which is going to be presented
on package upgrades. Can you please provide a wording for that text that you
would have been useful to you?

Thank you


-- 
regards,
Reinhard

Bug#1050299: rust-webpki: RUSTSEC-2023-0052

[Reinhard Tartler]

Hi Salvatore,

thanks for filing this bug.

> Please see https://rustsec.org/advisories/RUSTSEC-2023-0052.html .

This page is giving a very general description of the problem:

>> When this crate is given a pathological certificate chain to validate, it
>> will spend CPU time exponential with the number of candidate certificates at
>> each step of path building.

>>Both TLS clients and TLS servers that accept client certificate are affected.


The page is also indicating that the issue was fixed in version 0.22.1, hence,
I've packaged that version and closed this bug. While this might not address
all concerns, (at least https://github.com/briansmith/webpki/issues/69
indicates that there is more work to do),
https://github.com/briansmith/webpki/issues/69#issuecomment-1699894848
indicates:


>> There is a webpki 0.22.1 release that implements the signature count 
>> mitigation.


Additional, you are asking:

> Should rust-webpki be removed from Debian testing and unstable?

```
siretart@coccia:~$ dak rm -nR  rust-webpki
Will remove the following packages from unstable:

librust-webpki-dev |   0.22.0-2 | amd64, arm64, armel, armhf, i386
rust-webpki |   0.22.0-2 | source

Maintainer: Debian Rust Maintainers 


--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.
```

I think this indicates that it can indeed be safely removed from Debian? I'm
CC'ing developers that have made uploads to this packages in the past for
additiponal opinions as I suspect the issue is more subtle than that.

-rt

Bug#1051409: podman: Podman man pages use en-dash instead of dash

[Reinhard Tartler]

Control: reassign -1 go-md2man-v2
stop

Thanks for your report Guy,

All manpages in podman are written in markdown, and you can review the
sources at
https://github.com/containers/podman/blob/main/docs/source/Introduction.rst
-- as you can see the sources do not contain any unicode characters.

I strongly suspect that the unicode characters are introduced via the
go-md2man utility. I'm reassigning this to that package for additional
thoughts and suggestions. Please feel free to reassign back if this isn't
coming from e.g.
https://github.com/cpuguy83/go-md2man/blob/master/md2man/roff.go but
something in the libpod packaging.




On Thu, Sep 7, 2023 at 9:24 AM Guy Rutenberg  wrote:

> Package: podman
> Version: 4.3.1+ds1-8+b2
> Severity: minor
> X-Debbugs-Cc: guyrutenb...@gmail.com
>
> Dear Maintainer,
>
> The man pages supplied by the podman package use unicode en-dash (‐) to
> document flags instead of regular dash (-). This is both inconvinient when
> try
> to search the man page, and incorrect (as you would use normal dash in the
> shell).
>
> Thanks,
> Guy
>
>
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 6.4.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
> Locale: LANG=en_IL, LC_CTYPE=en_IL (charmap=UTF-8), LANGUAGE=en_IL:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages podman depends on:
> ii  conmon   2.1.6+ds1-1
> ii  golang-github-containers-common  0.50.1+ds1-4
> ii  libc62.37-7
> ii  libdevmapper1.02.1   2:1.02.185-2
> ii  libgpgme11   1.18.0-3+b1
> ii  libseccomp2  2.5.4-1+b3
> ii  libsubid41:4.13+dfsg1-1+b1
> ii  runc 1.1.5+ds1-1+b2
>
> Versions of packages podman recommends:
> ii  buildah1.28.2+ds1-3+b2
> ii  dbus-user-session  1.14.10-1
> ii  fuse-overlayfs 1.10-1
> ii  slirp4netns1.2.0-1
> ii  tini   0.19.0-1
> ii  uidmap 1:4.13+dfsg1-1+b1
>
> Versions of packages podman suggests:
> pn  containers-storage  
> pn  docker-compose  
> ii  iptables1.8.9-2
>
> -- Configuration Files:
> /etc/cni/net.d/87-podman-bridge.conflist [Errno 13] Permission denied:
> '/etc/cni/net.d/87-podman-bridge.conflist'
>
> -- no debconf information
>


-- 
regards,
Reinhard

Bug#1051202: docker.io: Please upgrade to upstream version 24 or later

[Reinhard Tartler]

Package: docker-doc
Severity: wishlist
X-Debbugs-Cc: none, Reinhard Tartler 

While trying to upgrade podman to 4.5, I got these compilation issues:

# github.com/containers/podman/pkg/api/handlers/swagger
src/github.com/containers/podman/pkg/api/handlers/swagger/responses.go:243:20: 
undefined: dockerVolume.Volume
src/github.com/containers/podman/pkg/api/handlers/swagger/responses.go:257:20: 
undefined: dockerVolume.ListResponse

I'll try to patch podman to use the older API, but it seems to me the
docker.io package in debian is lagging several upstream releases behind
anyways.

any plans to upgrade it soon?

-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.4.0-3-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#1050314: Additional dependencies needed

[Reinhard Tartler]

While working on the rekor package, I noticed a couple of missing dependencies, 
see log below.

Any suggestions for in-archive alternatives or assistance with packaging them?
-- I'm also considering disabling code, as I'm mostly interested in rekor as a
dependency of containers/image...


   dh_auto_build -O--builddirectory=_build -O--buildsystem=golang
_build/src/github.com/sigstore/rekor/cmd/backfill-redis/main.go:39:2: cannot 
find package "github.com/mediocregopher/radix/v4" in any of:
/usr/lib/go-1.21/src/github.com/mediocregopher/radix/v4 (from $GOROOT)
/<>/_build/src/github.com/mediocregopher/radix/v4 (from 
$GOPATH)
_build/src/github.com/sigstore/rekor/pkg/util/checkpoint.go:28:2: cannot find 
package "github.com/google/trillian/types" in any of:
/usr/lib/go-1.21/src/github.com/google/trillian/types (from $GOROOT)
/<>/_build/src/github.com/google/trillian/types (from 
$GOPATH)
_build/src/github.com/sigstore/rekor/pkg/types/entries.go:26:2: cannot find 
package 
"github.com/cyberphone/json-canonicalization/go/src/webpki.org/jsoncanonicalizer"
 in any of:

/usr/lib/go-1.21/src/github.com/cyberphone/json-canonicalization/go/src/webpki.org/jsoncanonicalizer
 (from $GOROOT)

/<>/_build/src/github.com/cyberphone/json-canonicalization/go/src/webpki.org/jsoncanonicalizer
 (from $GOPATH)
_build/src/github.com/sigstore/rekor/pkg/pki/pkcs7/pkcs7.go:30:2: cannot find 
package "github.com/sassoftware/relic/lib/pkcs7" in any of:
/usr/lib/go-1.21/src/github.com/sassoftware/relic/lib/pkcs7 (from 
$GOROOT)
/<>/_build/src/github.com/sassoftware/relic/lib/pkcs7 
(from $GOPATH)
_build/src/github.com/sigstore/rekor/pkg/pki/tuf/tuf.go:25:2: cannot find 
package "github.com/tent/canonical-json-go" in any of:
/usr/lib/go-1.21/src/github.com/tent/canonical-json-go (from $GOROOT)
/<>/_build/src/github.com/tent/canonical-json-go (from 
$GOPATH)
_build/src/github.com/sigstore/rekor/pkg/types/cose/v0.0.1/entry.go:35:2: 
cannot find package "github.com/in-toto/in-toto-golang/in_toto" in any of:
/usr/lib/go-1.21/src/github.com/in-toto/in-toto-golang/in_toto (from 
$GOROOT)
/<>/_build/src/github.com/in-toto/in-toto-golang/in_toto 
(from $GOPATH)
_build/src/github.com/sigstore/rekor/pkg/types/cose/v0.0.1/entry.go:37:2: 
cannot find package "github.com/veraison/go-cose" in any of:
/usr/lib/go-1.21/src/github.com/veraison/go-cose (from $GOROOT)
/<>/_build/src/github.com/veraison/go-cose (from $GOPATH)
_build/src/github.com/sigstore/rekor/pkg/types/jar/v0.0.1/entry.go:46:2: cannot 
find package "github.com/sassoftware/relic/lib/signjar" in any of:
/usr/lib/go-1.21/src/github.com/sassoftware/relic/lib/signjar (from 
$GOROOT)
/<>/_build/src/github.com/sassoftware/relic/lib/signjar 
(from $GOPATH)
_build/src/github.com/sigstore/rekor/pkg/types/rfc3161/v0.0.1/entry.go:35:2: 
cannot find package "github.com/sassoftware/relic/lib/pkcs9" in any of:
/usr/lib/go-1.21/src/github.com/sassoftware/relic/lib/pkcs9 (from 
$GOROOT)
/<>/_build/src/github.com/sassoftware/relic/lib/pkcs9 
(from $GOPATH)
_build/src/github.com/sigstore/rekor/pkg/types/rpm/v0.0.1/entry.go:33:2: cannot 
find package "github.com/cavaliercoder/go-rpm" in any of:
/usr/lib/go-1.21/src/github.com/cavaliercoder/go-rpm (from $GOROOT)
/<>/_build/src/github.com/cavaliercoder/go-rpm (from 
$GOPATH)
_build/src/github.com/sigstore/rekor/cmd/backfill-redis/main.go:40:2: cannot 
find package "sigs.k8s.io/release-utils/version" in any of:
/usr/lib/go-1.21/src/sigs.k8s.io/release-utils/version (from $GOROOT)
/<>/_build/src/sigs.k8s.io/release-utils/version (from 
$GOPATH)
_build/src/github.com/sigstore/rekor/pkg/sharding/ranges.go:29:2: cannot find 
package "github.com/google/trillian" in any of:
/usr/lib/go-1.21/src/github.com/google/trillian (from $GOROOT)
/<>/_build/src/github.com/google/trillian (from $GOPATH)
_build/src/github.com/sigstore/rekor/pkg/verify/verify.go:34:2: cannot find 
package "github.com/transparency-dev/merkle/proof" in any of:
/usr/lib/go-1.21/src/github.com/transparency-dev/merkle/proof (from 
$GOROOT)
/<>/_build/src/github.com/transparency-dev/merkle/proof 
(from $GOPATH)
_build/src/github.com/sigstore/rekor/pkg/verify/verify.go:35:2: cannot find 
package "github.com/transparency-dev/merkle/rfc6962" in any of:
/usr/lib/go-1.21/src/github.com/transparency-dev/merkle/rfc6962 (from 
$GOROOT)
/<>/_build/src/github.com/transparency-dev/merkle/rfc6962 
(from $GOPATH)
_build/src/github.com/sigstore/rekor/pkg/api/trillian_client.go:34:2: cannot 
find package "github.com/google/trillian/client" in any of:
/usr/lib/go-1.21/src/github.com/google/trillian/client (from $GOROOT)
/<>/_build/src/github.com/google/trillian/client (from 
$GOPATH)
_build/src/github.com/sigstore/rekor/pkg/signer/signer.go:24:2: cannot find 
package 

Bug#1050314: ITP: golang-github-sigstore-rekor -- Software Supply Chain Transparency Log

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-sigstore-rekor
  Version : 1.2.2-1
  Upstream Author : sigstore
* URL : https://github.com/sigstore/rekor
* License : Apache-2.0
  Programming Lang: Go
  Description : Software Supply Chain Transparency Log

 Rekor's goals are to provide an immutable tamper resistant ledger of
 metadata generated within a software projects supply chain. Rekor will
 enable software maintainers and build systems to record signed metadata
 to an immutable record. Other parties can then query said metadata to
 enable them to make informed decisions on trust and non-repudiation of an
 object's lifecycle.
 .
 The Rekor project provides a restful API based server for validation and
 a transparency log for storage. A CLI application is available to make
 and verify entries, query the transparency log for inclusion proof,
 integrity verification of the transparency log or retrieval of entries
 by either public key or artifact.
 .
 Rekor fulfils the signature transparency role of sigstore's software
 signing infrastructure. However, Rekor can be run on its own and is
 designed to be extensible to working with different manifest schemas and
 PKI tooling.

This package will be maintained under the pkg-golang community's umbrella.
It is going to be used by container management tools that are linked into
podman

Bug#1042194: netavark: FTBFS: unsatisfiable build-dependencies: librust-netlink-packet-core-0.4+default-dev (>= 0.4.2-~~), librust-netlink-packet-core-0.4+default-dev (>= 0.4.2-~~)

[Reinhard Tartler]

Thank you so much for these patches.

May I ask you to NMU this and and potentially aardvark-dns as necessary? -- I'm 
about to start traveling, and will have very limited internet access. No need 
to wait for NMU delays or things. Your diff looks great to me!

best,
-rt

On 8/10/23 8:37 PM, Peter Green wrote:

tags 1042194 +patch
thanks


During a rebuild of all packages in sid, your package failed to build
on amd64.


The attached patch makes netavark build again (note: some of the packages
it depends on have only just been accepted, so it may be a little time
before binaries are available in sid).

Bug#1041040: Fwd: Bug#1041040: aspectc++ autopkg tests fail with GCC 13

[Reinhard Tartler]

On 7/23/23 9:13 AM, Reinhard Tartler wrote:


Turns out, the fix only works on amd64/i386, but not for instance on Arm, 
Matthias, our GCC maintainer has filed 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041040 for this.

I looked over the patch and couldn't find anything architecture specific. Can 
you make any rhyme or reason for why it might fail on arm64?

Here are some more test logs:
https://ci.debian.net/packages/a/aspectc++/unstable/arm64/


This issue also occurs during a regular package build, not only during 
autopkgtest. I could reproduce it on the amdhal.debian.org in a sid chroot and 
got this:

Weaving aspects into PreFileIncluder.cc...
  
Weaving aspects into PreprocessorParser.cc...

Weaving aspects into UnitManager.cc...
In file included from 
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/src/PreFileIncluder.cc:19:
In file included from 
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/TokenStream.h:25:
In file included from 
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/Array.h:27:
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/Array.h_0_virt:66:9:
 error: __float128 is not supported on this target
typedef __float128 _Float128;
^
In file included from 
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/src/PrePrintVisitor.cc:19:
In file included from 
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/PreSemIterator.h:24:
In file included from 
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/PreTreeIterator.h:24:
In file included from 
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/PreTree.h:25:
In file included from 
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/PreVisitor.h:24:
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/PreVisitor.h_0_virt:66:9:
 error: __float128 is not supported on this target
typedef __float128 _Float128;
^
In file included from 
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/src/PreprocessorParser.cc:19:
In file included from 
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/Token.h:25:
In file included from 
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/LanguageID.h:25:
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/LanguageID.h_0_virt:66:9:
 error: __float128 is not supported on this target
typedef __float128 _Float128;
^
In file included from 
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/src/UnitManager.cc:19:
In file included from 
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/Unit.h:25:
In file included from 
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/List.h:25:
In file included from 
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/ListElement.h:27:
/tmp/autopkgtest.sSXQhw/build.5EQ/src/Puma/gen-release/step1/inc/Puma/ListElement.h_0_virt:66:9:
 error: __float128 is not supported on this target
typedef __float128 _Float128;
^

Bug#1041747: ITP: golang-github-containers-libtrust -- Primitives for identity and authorization

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-containers-libtrust
  Version : 0.0~git20230121.c1716e8-1
  Upstream Author : Containers
* URL : https://github.com/containers/libtrust
* License : Apache-2.0
  Programming Lang: Go
  Description : Primitives for identity and authorization

 Libtrust is library for managing authentication and authorization using
 public key cryptography.
 .
 Authentication is handled using the identity attached to the public key.
 Libtrust provides multiple methods to prove possession of the private
 key associated with an identity.
 .
  * TLS x509 certificates
  * Signature verification
  * Key Challenge
 .
 Authorization and access control is managed through a distributed trust
 graph. Trust servers are used as the authorities of the trust graph and
 allow caching portions of the graph for faster access.
 .
 This package contains a fork of Docker's libtrust that is being worked
 by the github containers commnuity.

Bug#1029170: ITP: golang-github-sigstore-sigstore -- Common go library shared across sigstore services and clients

[Reinhard Tartler]

Hi Leo,

I hope you are well. Now that all dependencies to build this package are
in place, I've taken the liberty of uploading the package to
debian/experimental and pushed my sources to
https://salsa.debian.org/go-team/packages/golang-github-sigstore-sigstore

I really don't want this to be seen as an ITP takeover, since we've been
talking on this ITP for a while, I hope that's okay. Please take a look at
this repo and at
https://ftp-master.debian.org/new/golang-github-sigstore-sigstore_1.4.0-1.html
and let me know what you think.

Best,
-rt

-- 
regards,
Reinhard

Bug#1040877: netavark: phasing out clap version 3.

[Reinhard Tartler]

Hi Peter,


Thanks for the report!

On 7/11/23 4:39 PM, Peter Green wrote:

Please consider moving to clap v4.



Gladly. The thing is, netavark and aardvark-dns need to be updated in lockstep. 
I've started looking into this, and then got stuck with a number of additional 
required dependencies. I'm currently stuck at 'rust-mozim', which in turn drags 
in a number of additional deps, such as ethtool, and (potentially required) 
version upgrades to the various netlink and rtnetlink packages.

Let's coordinate on IRC/matrix for packaging those dependencies.

Thanks,
-rt

Bug#1030557: golang-github-theupdateframework-go-tuf is still stuck in NEW

[Reinhard Tartler]

Dear ftp-master,

On 6/26/23 1:30 PM, Reinhard Tartler wrote:

Dear ftp-masters,

I notice that
https://ftp-master.debian.org/new/golang-github-theupdateframework-go-tuf_0.5.2-1.html
is being reviewed since 5 months. I wonder whether there are any issues or
questions with the upload I might be able to help resolving?

The thing is, I'd really would like to continue working on packaging cosign
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030557), a package for
signing container images, and this this package is a code dependency.



I'm really eager to continue packaging newer versions of podman, which make it
harder and harder to package without cosign, for which I need this package in 
Debian.

Any chance you could give me a hand with golang-github-theupdateframework-go-tuf
which is still stuck in NEW?

Thank you for your help!
 

Bug#1030557: golang-github-theupdateframework-go-tuf is still stuck in NEW

[Reinhard Tartler]

Dear ftp-masters,

I notice that
https://ftp-master.debian.org/new/golang-github-theupdateframework-go-tuf_0.5.2-1.html
is being reviewed since 5 months. I wonder whether there are any issues or
questions with the upload I might be able to help resolving?

The thing is, I'd really would like to continue working on packaging cosign
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030557), a package for
signing container images, and this this package is a code dependency.

Thank you for your help!

-- 
regards,
Reinhard

Bug#1038784: O: gpac -- GPAC Project on Advanced Content - utilities

[Reinhard Tartler]

Package: wnpp
Severity: normal
X-Debbugs-Cc: g...@packages.debian.org
Control: affects -1 + src:gpac

I intend to orphan the gpac package because I'm no longer able to bring up
the time and energy for properly maintaining this package.

The package description is:
 GPAC stands for GPAC Project on Advanced Content (a recursive acronym). It is
 an Open Source multimedia framework for research and academic purposes. The
 project covers different aspects of multimedia, with a focus on presentation
 technologies (graphics, animation and interactivity).
 .
 This package contains the following utilities:
   - MP4Box

It has a bit of a complicated security history but has recently
(the last few years) gotten much more attention upstream.

I wish that project propsective maintainers best of luck!

Bug#1034871: podman: "sudo podman system reset" can delete current working directory

[Reinhard Tartler]

Control: tag -1 +upstream
Control: forwarded -1 https://github.com/containers/podman/issues/18349
Control: severity -1 important

On Wed, Apr 26, 2023 at 6:48 AM Jan Hendrik Farr  wrote:

> Package: podman
> Version: 4.3.1+ds1-6+b2
> Severity: normal
> Tags: newcomer
> X-Debbugs-Cc: deb...@jfarr.cc
>
> Dear Maintainer,
>
> if /etc/containers/storage.conf does not include the runRoot variable, then
> running "sudo podman system reset" will delete the current working
> directory.
> This is already fixed in upstream, I hope this can be backported and
> included
> in Debian 12.
>
> upstream issue: https://github.com/containers/podman/issues/18349
> upstream fix: https://github.com/containers/storage/pull/1510
>
>
> Including this fix in Debian 12 has a really low chance of affecting other
> packages, but if this fix is not included there will inevitably be more
> people
> like me that accidentally remove their home directory.
>

It indeed sounds like a significant papercut. I'm seeking for further
thoughts and opinions: Is this something worth backporting that late in the
release cycle?

-rt

Bug#1029170: ITP: golang-github-sigstore-sigstore -- Common go library shared across sigstore services and clients

[Reinhard Tartler]

On Thu, Apr 13, 2023 at 6:46 AM Reinhard Tartler  wrote:

>
> -- unfortunately, I made a mistake: I packaged version 3 of
> jellydator-ttlcache, which has a significantly different API than version2,
> which sigstore currently uses.
>
> I'm considering either downgrading the package, or making sigstore use v3.
> I guess the latter is better in the long term. Mh.
>
>
https://github.com/sigstore/sigstore/pull/1099 to make up for that mistake

-- 
regards,
Reinhard

Bug#1034493: bullseye-pu: package libpod/3.0.1+dfsg1-3+deb11u4

[Reinhard Tartler]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: lib...@packages.debian.org
Control: affects -1 + src:libpod

[ Reason ]
Podman relies on DBUS for correct functioning and reads the
DBUS_SESSION_BUS_ADDRESS environent variables. As it turns out, some session
managers use multiple values, separated by comma, to add additional
information, such as a "guid". Unfortunately, an oversight in the parsing code
in podman 3 fails to take multi-value items into account and leads to podman
failing to connect to the session bus.

This is a rebuild to pickup the changes approved via #1034198

[ Impact ]
This is highly inconvenient to the users as they would have to either use a
session manager that sets the DBUS_SESSION_BUS_ADDRESS without commas, or the
user would have to sanitize the environment manually. Only very highly skilled
users that happened to find https://github.com/containers/podman/issues/15546 or
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018816 would be able to 
figure
this out.

[ Tests ]
This was manually tested.

[ Risks ]
the risk of regression is minimal, the patch was taken from upstream, and is 
included
in later releases.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
diff -Nru libpod-3.0.1+dfsg1/debian/changelog 
libpod-3.0.1+dfsg1/debian/changelog
--- libpod-3.0.1+dfsg1/debian/changelog 2023-04-07 22:10:33.0 -0400
+++ libpod-3.0.1+dfsg1/debian/changelog 2023-04-16 18:16:11.0 -0400
@@ -1,3 +1,9 @@
+libpod (3.0.1+dfsg1-3+deb11u4) bullseye; urgency=medium
+
+  * Recompile to fix parsing of DBUS_SESSION_BUS_ADDRESS (Closes: #1018816)
+
+ -- Reinhard Tartler   Sun, 16 Apr 2023 18:16:11 -0400
+
 libpod (3.0.1+dfsg1-3+deb11u3) bullseye; urgency=medium
 
   * Fix and tighten dependencies
diff -Nru libpod-3.0.1+dfsg1/debian/control libpod-3.0.1+dfsg1/debian/control
--- libpod-3.0.1+dfsg1/debian/control   2023-04-07 22:10:33.0 -0400
+++ libpod-3.0.1+dfsg1/debian/control   2023-04-16 18:16:11.0 -0400
@@ -18,7 +18,7 @@
 ,golang-github-containerd-cgroups-dev
 ,golang-github-containernetworking-plugins-dev (>= 0.8.7)
 ,golang-github-containers-buildah-dev (>= 1.19.6)
-,golang-github-containers-common-dev (>= 0.33.4+ds1-1+deb11u1)
+,golang-github-containers-common-dev (>= 0.33.4+ds1-1+deb11u2)
 ,golang-github-containers-image-dev (>= 5.10.2)
 ,golang-github-containers-ocicrypt-dev
 ,golang-github-containers-psgo-dev (>= 1.5.2-1+deb11u1)
@@ -137,7 +137,7 @@
 ,golang-github-containerd-cgroups-dev
 ,golang-github-containernetworking-plugins-dev (>= 0.8.7)
 ,golang-github-containers-buildah-dev (>= 1.19)
-,golang-github-containers-common-dev (>= 0.33.4+ds1-1+deb11u1)
+,golang-github-containers-common-dev (>= 0.33.4+ds1-1+deb11u2)
 ,golang-github-containers-image-dev (>= 5.10)
 ,golang-github-containers-ocicrypt-dev
 ,golang-github-containers-psgo-dev (>= 1.5.2-1+deb11u1)

Bug#1034480: ITP: golang-github-google-go-containerregistry -- Go library and CLIs for working with container registries

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-google-go-containerregistry
  Version : 0.14.0-1
  Upstream Author : Google
* URL : https://github.com/google/go-containerregistry
* License : Apache-2.0
  Programming Lang: Go
  Description : Go library and CLIs for working with container registries

This package is used as a library by other package, such as sigstore (cf. 
#1029170)

It does contain some utilities, but don't plan on building those at this point,
as they require additional dependencies. Also, the libraries does have some code
to interact (authenticate) with kubernetes, but this isn't available in Debian
at this point.

Bug#1029170: ITP: golang-github-sigstore-sigstore -- Common go library shared across sigstore services and clients

[Reinhard Tartler]

On Wed, Apr 12, 2023 at 3:53 PM Leo Antunes  wrote:

> Sorry for the late reply. My laptop decided it was a good time to break,
> so I'll have even less time to work on this in the next few days/weeks :/
>
> --- Original Message ---
> On Sunday, March 26th, 2023 at 22:07, Reinhard Tartler 
> wrote:
>
> > Sounds good.
> >
> > I'm happy to take on the easier dependencies, such as pkg/browser or
> jellydator/ttlcache.
>
>
> That would be a huge help already!
>
>
https://tracker.debian.org/pkg/golang-github-jellydator-ttlcache
https://tracker.debian.org/pkg/golang-github-pkg-browser

you're welcome :-)

-- unfortunately, I made a mistake: I packaged version 3 of
jellydator-ttlcache, which has a significantly different API than version2,
which sigstore currently uses.

I'm considering either downgrading the package, or making sigstore use v3.
I guess the latter is better in the long term. Mh.


> > But the dependency on boulder is giving me a massive headache. It is
> really unfortunate that they chose to use such a heavy dependency for a
> rather simple task (goodkey). What are your thoughts on resolving this?
>
>
> I didn't dive deep into the code, but I suspect we can patch away the
> boulder dep. I'll gladly give it a try as soon as I have a workable laptop
> again (but feel free to jump in if you find the time!)
>
>
I think this patch should do it:

modified   pkg/cryptoutils/publickey.go
@@ -16,7 +16,6 @@
 package cryptoutils

 import (
- "context"
  "crypto"
  "crypto/ecdsa"
  "crypto/ed25519"
@@ -30,8 +29,6 @@ import (
  "encoding/pem"
  "errors"
  "fmt"
-
- "github.com/letsencrypt/boulder/goodkey"
 )

 const (
@@ -139,20 +136,8 @@ func genErrMsg(first, second crypto.PublicKey, keyType
string) string {
 func ValidatePubKey(pub crypto.PublicKey) error {
  switch pk := pub.(type) {
  case *rsa.PublicKey:
- // goodkey policy enforces:
- // * Size of key: 2048 <= size <= 4096, size % 8 = 0
- // * Exponent E = 65537 (Default exponent for OpenSSL and Golang)
- // * Small primes check for modulus
- // * Weak keys generated by Infineon hardware (see
https://crocs.fi.muni.cz/public/papers/rsa_ccs17)
- // * Key is easily factored with Fermat's factorization method
- p, err := goodkey.NewKeyPolicy({FermatRounds: 100}, nil)
- if err != nil {
- // Should not occur, only chances to return errors are if fermat rounds
- // are <0 or when loading blocked/weak keys from disk (not used here)
- return errors.New("unable to initialize key policy")
- }
- // ctx is unused
- return p.GoodKey(context.Background(), pub)
+ // Avoid dependency on Goodkey for debian
+ return nil;
  case *ecdsa.PublicKey:
  // Unable to use goodkey policy because P-521 curve is not supported
  return validateEcdsaKey(pk)
modified   pkg/cryptoutils/publickey_test.go
@@ -183,6 +183,8 @@ func TestValidatePubKeyUnsupported(t *testing.T) {
 }

 func TestValidatePubKeyRsa(t *testing.T) {
+ t.Skip("Validations disabled for Debian")
+
  // Validate common RSA key sizes
  for _, bits := range []int{2048, 3072, 4096} {
  priv, err := rsa.GenerateKey(rand.Reader, bits)



-- 
regards,
Reinhard

Bug#1034026: podman-docker: missing /usr/share/user-tmpfiles.d/podman-docker.conf

[Reinhard Tartler]

Control: tag -1 help

On Thu, Apr 6, 2023 at 2:06 PM Scott Edlund  wrote:

> podman-docker.conf was configured for use with rootless podman starting
> in 4.3.0rc1 .   Please install the tmpfiles configuration also in
> user-tmpfiles.
>
> See
>
> https://github.com/containers/podman/commit/b47c54ab69d56f05bc586e443d04fe572de8ff8f
>
>
It seems that dh_installtmpfiles(1) does not take care of that, I hoped
that it would.

I'm struggling to find out what's the right debhelper to use here. Any
suggestions on
how to modify
https://salsa.debian.org/debian/libpod/-/tree/debian/sid/debian in
the most elegant way?

-rt


-- 
regards,
Reinhard

Bug#1033826: podman: Cannot load gzip compressed images

[Reinhard Tartler]

On Wed, Apr 12, 2023 at 6:41 AM Reinhard Tartler  wrote:

> Control: reassign -1 golang-github-klauspost-pgzip 1.2.5-2
> Control: affects -1 libpod
> Control: forwarded -1 https://github.com/containers/podman/issues/15944
> Control: severity -1 important
>
>
I've prepared an MR for this at
https://salsa.debian.org/go-team/packages/golang-github-klauspost-pgzip/-/merge_requests/4

I'm looking for opinions whether this code change is appropriate for
bookwork at this point.

Best,
-rt

-- 
regards,
Reinhard

Bug#1033826: podman: Cannot load gzip compressed images

[Reinhard Tartler]

Control: reassign -1 golang-github-klauspost-pgzip 1.2.5-2
Control: affects -1 libpod
Control: forwarded -1 https://github.com/containers/podman/issues/15944
Control: severity -1 important

Hi Antonio,

Thanks for your report.

I've looked through the source code, and while the exact error message
doesn't exactly match, I did confirm that the current debian/sid podman is
indeed built with golang 1.19, and uses an older version of
klauspost/pgzip that doesn't have that code change from
https://github.com/klauspost/pgzip/pull/50. I'd argue it is necessary for
golang 1.19.

In order to fix this, the code change needs to go into pgzip and libpod
needs to be rebuilt.

-rt

On Sun, Apr 2, 2023 at 6:51 AM Antonio Cebrián  wrote:

> Package: podman
> Version: 4.3.1
>
>
> Podman cannot load images compressed with gzip. Uncompressed images or
> bzip2 compressed images work right therefore it seems to be a problem
> related to gzip handling.
>
> It seems to be the same problem reported here:
>
> https://github.com/containers/podman/issues/15944
>
>
> Tested under Bookworm with podman 4.3.1:
>
> *$ podman image pull hello-world:latest*
> Resolved "hello-world" as an alias
> (/etc/containers/registries.conf.d/shortnames.conf)
> Trying to pull docker.io/library/hello-world:latest...
> Getting image source signatures
> Copying blob 2db29710123e done
> Copying config feb5d9fea6 done
> Writing manifest to image destination
> Storing signatures
> feb5d9fea6a5e9606aa995e879d862b825965ba48de054caab5ef356dc6b3412
>
> *$ podman image save hello-world:latest > hello-world.tar*
>
> *$ podman image save hello-world:latest | gzip > hello-world.tar.gz*
>
> *$ podman image save hello-world:latest | bzip2 > hello-world.tar.bz2*
>
> *$ podman image load -i hello-world.tar*
> Getting image source signatures
> Copying blob e07ee1baac5f skipped: already exists
> Copying config feb5d9fea6 done
> Writing manifest to image destination
> Storing signatures
> Loaded image: docker.io/library/hello-world:latest
>
> *$ podman image load -i hello-world.tar.gz*
> Error: payload does not match any of the supported image formats:
>  * oci: initializing source oci:hello-world.tar.gz:: open
> hello-world.tar.gz/index.json: not a directory
>  * oci-archive: loading index: open /var/tmp/oci3062655986/index.json: no
> such file or directory
>  * docker-archive: loading tar component manifest.json: unexpected EOF
>  * dir: open hello-world.tar.gz/manifest.json: not a directory
>
> *$ podman image load -i hello-world.tar.bz2*
> Getting image source signatures
> Copying blob e07ee1baac5f skipped: already exists
> Copying config feb5d9fea6 done
> Writing manifest to image destination
> Storing signatures
> Loaded image: docker.io/library/hello-world:latest
>
>
> Attached you have the debug output of the failing command:
>
> *$ podman --debug image load -i hello-world.tar.gz*
>
>
> In Bullseye with podman 3.0.1 all works as expected:
>
> *$ podman image pull hello-world:latest*
> Resolved "hello-world" as an alias
> (/etc/containers/registries.conf.d/shortnames.conf)
> Trying to pull docker.io/library/hello-world:latest...
> Getting image source signatures
> Copying blob 2db29710123e done
> Copying config feb5d9fea6 done
> Writing manifest to image destination
> Storing signatures
> feb5d9fea6a5e9606aa995e879d862b825965ba48de054caab5ef356dc6b3412
>
> *$ podman image save hello-world:latest > hello-world.tar*
> Copying blob e07ee1baac5f done
> Copying config feb5d9fea6 done
> Writing manifest to image destination
> Storing signatures
>
> *$ podman image save hello-world:latest | gzip > hello-world.tar.gz*
> Copying blob e07ee1baac5f done
> Copying config feb5d9fea6 done
> Writing manifest to image destination
> Storing signatures
>
> *$ podman image save hello-world:latest | bzip2 > hello-world.tar.bz2*
> Copying blob e07ee1baac5f done
> Copying config feb5d9fea6 done
> Writing manifest to image destination
> Storing signatures
>
> *$ podman image load -i hello-world.tar*
> Getting image source signatures
> Copying blob e07ee1baac5f [--] 0.0b /
> 0.0b
> Copying config feb5d9fea6 done
> Writing manifest to image destination
> Storing signatures
> Loaded image(s): docker.io/library/hello-world:latest
>
> *$ podman image load -i hello-world.tar.gz*
> Getting image source signatures
> Copying blob e07ee1baac5f skipped: already exists
> Copying config feb5d9fea6 done
> Writing manifest to image destination
> Storing signatures
> Loaded image(s): docker.io/library/hello-world:latest
>
> *$ podman image load -i hello-world.tar.bz2*
> Getting image source signatures
> Copying blob e07ee1baac5f [--] 0.0b /
> 0.0b
> Copying config feb5d9fea6 done
> Writing manifest to image destination
> Storing signatures
> Loaded image(s): docker.io/library/hello-world:latest
>
>
> Best regards.
>
>

-- 
regards,
Reinhard

Bug#1034198: bullseye-pu: package golang-github-containers-common/0.33.4+ds1-1+deb11u1

[Reinhard Tartler]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: golang-github-containers-com...@packages.debian.org, 
siret...@tauware.de
Control: affects -1 + src:golang-github-containers-common

[ Reason ]

Podman relies on DBUS for correct functioning and reads the
DBUS_SESSION_BUS_ADDRESS environent variables. As it turns out, some session
managers use multiple values, separated by comma, to add additional
information, such as a "guid". Unfortunately, an oversight in the parsing code
in podman 3 fails to take multi-value items into account and leads to podman
failing to connect to the session bus.

[ Impact ]
This is highly inconvenient to the users as they would have to either use a
session manager that sets the DBUS_SESSION_BUS_ADDRESS without commas, or the
user would have to sanitize the environment manually. Only very highly skilled
users that happened to find https://github.com/containers/podman/issues/15546 or
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018816 would be able to 
figure
this out.

[ Tests ]
This was manually tested.

[ Risks ]
the risk of regression is minimal, the patch was taken from upstream, and is 
included
in later releases.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
diff --git a/debian/changelog b/debian/changelog
index c23b4b9b..97d97794 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+golang-github-containers-common (0.33.4+ds1-1+deb11u2) bullseye; urgency=medium
+
+  * Fix parsing of DBUS_SESSION_BUS_ADDRESS, Closes: #1018816
+
+ -- Reinhard Tartler   Mon, 10 Apr 2023 18:19:51 -0400
+
 golang-github-containers-common (0.33.4+ds1-1+deb11u1) bullseye; urgency=medium
 
   * Backport seccomp patches from upstream to allow execution of newer
diff --git a/debian/patches/DBUS_SESSION_BUS_ADDRESS_parsing.patch 
b/debian/patches/DBUS_SESSION_BUS_ADDRESS_parsing.patch
new file mode 100644
index ..d1408a43
--- /dev/null
+++ b/debian/patches/DBUS_SESSION_BUS_ADDRESS_parsing.patch
@@ -0,0 +1,37 @@
+commit 47ea9a8cbcc35d1e758b01ae40f37fec8a2e310b
+Author: Giuseppe Scrivano 
+Date:   Mon Jul 26 15:00:25 2021 +0200
+
+config: split arguments in DBUS_SESSION_BUS_ADDRESS
+
+split the DBUS_SESSION_BUS_ADDRESS value so that something like:
+
+unix:path=/run/user/1000/bus,guid=817e9ffcfb383869ad17ea8360e7428a
+
+will ignore ",guid=817e9ffcfb383869ad17ea8360e7428a" when checking
+that the path exists.
+
+Closes: https://bugzilla.redhat.com/show_bug.cgi?id=1984531
+
+Signed-off-by: Giuseppe Scrivano 
+
+--- a/pkg/config/config.go
 b/pkg/config/config.go
+@@ -538,9 +538,14 @@
+ 
+   session := os.Getenv("DBUS_SESSION_BUS_ADDRESS")
+   hasSession := session != ""
+-  if hasSession && strings.HasPrefix(session, "unix:path=") {
+-  _, err := os.Stat(strings.TrimPrefix(session, "unix:path="))
+-  hasSession = err == nil
++  if hasSession {
++  for _, part := range strings.Split(session, ",") {
++  if strings.HasPrefix(part, "unix:path=") {
++  _, err := os.Stat(strings.TrimPrefix(part, 
"unix:path="))
++  hasSession = err == nil
++  break
++  }
++  }
+   }
+ 
+   if !hasSession {
diff --git a/debian/patches/series b/debian/patches/series
index c2a2b119..201ff0d9 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -6,3 +6,4 @@ seccomp-fixup.patch
 08bbb0dfae71da36afd3be1ca104701e6cfa4406.patch
 0f242ca74bd16175bc55013ed457c88137bec0cf.patch
 689e5b074454da5228bb05604f89b7a876baa8fe.patch
+DBUS_SESSION_BUS_ADDRESS_parsing.patch

Bug#1030930: podman: DNS resolution fails in 'podman build' but works in 'podman run'

[Reinhard Tartler]

Control: tag -1 + unreproducible moreinfo

Hi Kevin,

great to hear from you in this space!

On Thu, Feb 9, 2023 at 8:36 AM Kevin P. Fleming  wrote:

> Package: podman
> Version: 4.3.1+ds1-5+b1
> Severity: important
>
> Dear Maintainer,
>
> I am seeing DNS resolution fail when using 'podman build' but succeed when
> using 'podman run', with a Dockerfile which contains the same commands I
> run
> manually in the 'podman run'-launched shell.
>
> Dockerfile
> --
> FROM alpine:3.10
> RUN cat /etc/resolv.conf
> RUN apk add tar
>

Unfortunately, I can't reproduce. Please help me to reproduce this issue.
Also, maybe upstream has an idea, can you please report this issue at
https://github.com/containers/podman/issues/new/choose. In any case, here
is the output that I get:

siretart@x1:/tmp/dnstest$ cat >> Containerfile
FROM alpine:3.10
RUN cat /etc/resolv.conf
RUN apk add tar
siretart@x1:/tmp/dnstest$ cat Containerfile
FROM alpine:3.10
RUN cat /etc/resolv.conf
RUN apk add tar
siretart@x1:/tmp/dnstest$ podman build .
STEP 1/3: FROM alpine:3.10
Resolved "alpine" as an alias
(/etc/containers/registries.conf.d/shortnames.conf)
Trying to pull docker.io/library/alpine:3.10...
Getting image source signatures
Copying blob 396c31837116 done
Copying config e7b300aee9 done
Writing manifest to image destination
Storing signatures
STEP 2/3: RUN cat /etc/resolv.conf
search int.tauware.de
nameserver 10.0.2.3
nameserver 192.168.88.3
--> 2ce59772eaf
STEP 3/3: RUN apk add tar
fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/main/x86_64/APKINDEX.tar.gz
fetch
http://dl-cdn.alpinelinux.org/alpine/v3.10/community/x86_64/APKINDEX.tar.gz
(1/1) Installing tar (1.32-r1)
Executing busybox-1.30.1-r5.trigger
OK: 6 MiB in 15 packages
COMMIT
--> 7c1bfd9e030
7c1bfd9e030f07b05cc9427a97c0bc5ff73bca5436bce389ad81da1a64f64a11



-- 
regards,
Reinhard

Bug#1034039: bullseye-pu: package libpod/3.0.1+dfsg1-3+deb11u1

[Reinhard Tartler]

Argh, my bad, I'll upload a new version later today

Thanks for spotting

-rt

On April 7, 2023 4:41:41 AM EST, "Adam D. Barratt"  
wrote:
>On Thu, 2023-04-06 at 19:46 -0400, Reinhard Tartler wrote:
>> This code change picks up code changes in golang-github-containers-
>> psgo
>> and golang-github-containers-storage to fix CVE-2022-1227. This is
>> reported
>> as 1020907. This addresses a priviledge escalation issue when using
>> 'podman top'. Upstream has more information in this issue in
>> https://bugzilla.redhat.com/show_bug.cgi?id=2070368
>> 
>
>I see this has already been uploaded; unfortunately:
>
>-,golang-github-containers-psgo-dev
>-,golang-github-containers-storage-dev (>= 1.24.6)
>+,golang-github-containers-psgo-dev (>= 1.5.2-1+deb11u1)
>+,golang-github-containers-storage-dev (>= 1.24.6+dfsg1-1+deb11u1)
>
>The updated golang-github-containers-storage-dev version there isn't
>actually sufficient to ensure that the fixed version is picked up - you
>want 1.24.*8*+dfsg1-1+deb11u1.
>
>At this point, either I can reject the current upload, and you can then
>re-upload a fixed +deb11u1 or (possibly easier all around) you can
>upload +deb11u2 as an incremental change on top of +deb11u1 which
>simply fixes the dependency version.
>
>Regards,
>
>Adam
>
>

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

Bug#1034039: bullseye-pu: package libpod/3.0.1+dfsg1-3+deb11u1

[Reinhard Tartler]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: lib...@packages.debian.org, siret...@tauware.de
Control: affects -1 + src:libpod

[ Reason ]
This code change picks up code changes in golang-github-containers-psgo
and golang-github-containers-storage to fix CVE-2022-1227. This is reported
as 1020907. This addresses a priviledge escalation issue when using
'podman top'. Upstream has more information in this issue in
https://bugzilla.redhat.com/show_bug.cgi?id=2070368

Additionally, another upstream code change is being backported to address
CVE-2022-27649. This is reported as #1020906. This is to address a
capability escalation issue on file descriptors that were not intended
to have inheritable capabilities.

[ Impact ]
Without this update, users remain vulnerable to the issues explained above.

[ Tests ]
I've manually built and installed the built package in a kvm virtual machine
and conducted some basic tests.

[ Risks ]
All patches have been cherry picked from the branches that redhat also
includes in RHEL.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
diff --git a/debian/changelog b/debian/changelog
index 12a2268bb..dbd215727 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+libpod (3.0.1+dfsg1-3+deb11u2) bullseye; urgency=medium
+
+  * CVE-2022-1227: pickup changes in containers/psgo, Closes: #1020907
+  * CVE-2022-27649: do not set the inheritable capabilities, Closes: #1020906
+
+ -- Reinhard Tartler   Wed, 05 Apr 2023 21:00:36 -0400
+
 libpod (3.0.1+dfsg1-3+deb11u1) bullseye; urgency=medium
 
   * Rebuild against containers-common to pickup seccomp updates required
diff --git a/debian/control b/debian/control
index 3df797b30..a8834b883 100644
--- a/debian/control
+++ b/debian/control
@@ -21,8 +21,8 @@ Build-Depends: debhelper-compat (= 12)
 ,golang-github-containers-common-dev (>= 0.33.4+ds1-1+deb11u1)
 ,golang-github-containers-image-dev (>= 5.10.2)
 ,golang-github-containers-ocicrypt-dev
-,golang-github-containers-psgo-dev
-,golang-github-containers-storage-dev (>= 1.24.6)
+,golang-github-containers-psgo-dev (>= 1.5.2-1+deb11u1)
+,golang-github-containers-storage-dev (>= 1.24.6+dfsg1-1+deb11u1)
 ,golang-github-coreos-bbolt-dev (>= 1.3.3~)
 ,golang-github-coreos-go-iptables-dev (>= 0.4.2~)
 ,golang-github-coreos-go-systemd-dev (>= 20~)
diff --git a/debian/patches/0001-do-not-set-the-inheritable-capabilities.patch 
b/debian/patches/0001-do-not-set-the-inheritable-capabilities.patch
new file mode 100644
index 0..3d7666b91
--- /dev/null
+++ b/debian/patches/0001-do-not-set-the-inheritable-capabilities.patch
@@ -0,0 +1,109 @@
+From d2848c0281ed94992c4b23c5899e36afc1af Mon Sep 17 00:00:00 2001
+From: Andre Moreira Magalhaes 
+Date: Mon, 19 Sep 2022 11:03:21 -0300
+Subject: [PATCH] do not set the inheritable capabilities
+
+The kernel never sets the inheritable capabilities for a process, they
+are only set by userspace.  Emulate the same behavior.
+
+Closes: CVE-2022-27649
+
+(backported from upstream commit 7b368768c2990b9781b2b6813e1c7f91c7e6cb13)
+---
+ libpod/oci_conmon_linux.go   | 7 +--
+ pkg/specgen/generate/security.go | 7 +--
+ test/e2e/run_test.go | 6 +++---
+ 3 files changed, 13 insertions(+), 7 deletions(-)
+
+diff --git a/libpod/oci_conmon_linux.go b/libpod/oci_conmon_linux.go
+index 38ffba7d2..b073feee1 100644
+--- a/libpod/oci_conmon_linux.go
 b/libpod/oci_conmon_linux.go
+@@ -1281,11 +1281,14 @@ func prepareProcessExec(c *Container, options 
*ExecOptions, env []string, sessio
+   } else {
+   pspec.Capabilities.Bounding = 
ctrSpec.Process.Capabilities.Bounding
+   }
++
++  // Always unset the inheritable capabilities similarly to what the 
Linux kernel does
++  // They are used only when using capabilities with uid != 0.
++  pspec.Capabilities.Inheritable = []string{}
++
+   if execUser.Uid == 0 {
+   pspec.Capabilities.Effective = pspec.Capabilities.Bounding
+-  pspec.Capabilities.Inheritable = pspec.Capabilities.Bounding
+   pspec.Capabilities.Permitted = pspec.Capabilities.Bounding
+-  pspec.Capabilities.Ambient = pspec.Capabilities.Bounding
+   } else {
+   if user == c.config.User {
+   pspec.Capabilities.Effective = 
ctrSpec.Process.Capabilities.Effective
+diff --git a/pkg/specgen/generate/security.go 
b/pkg/specgen/generate/security.go
+index fb45d87db..c18f83217 100644
+--- a/pkg/specgen/generate/security.go
 b/pkg/specgen/generate/security.go
+@@ -130,6 +130,10 @@ func securityConfigureGenerator(s *specgen.SpecGenerator, 
g *generate.Generator,
+ 
+ 

Bug#1027257: bullseye-pu: package golang-github-containers-storage/1.24.8+dfsg1-2~deb11u1

[Reinhard Tartler]

Control: tag -1 -moreinfo

On 4/1/23 7:04 PM, Reinhard Tartler wrote:



On 4/1/23 3:51 PM, Adam D. Barratt wrote:

Control: tags -1 + moreinfo

Apologies for the delay in getting back to you on this.

On Wed, 2022-12-28 at 22:26 -0500, Reinhard Tartler wrote:

In order to fix CVE-2022-1227, an update to golang-github-containers-
psgo
is needed, more specifically,
https://github.com/containers/psgo/pull/92

That patch introduces a dependency on golang-github-containers-
storage, and uses
the helper functions RawTo{Container,Host} which are introduced with
this patch.


[...]

The code changes adds a helper function that isn't used otherwise
yet.


Looking at the diff, it appears that what it actually does is rename
two existing helper functions, with no functional change to either. Am
I missing something?


You are correct. The patch renames the helper functions to an Uppercase 
spelling.
This exposes the function to other packages, which is being used in the patch
to fix CVE-2022-1227.

I would recommend approving this code change.


+golang-github-containers-storage (1.24.8+dfsg1-2~deb11u1) bullseye;
urgency=medium


Given what I can see of the package's upload history, the version
should rather be 1.24.8+dfsg1-1+deb11u1.


Will do!


Updated debdiff attached to this email.


Okay to upload now?


-rtdiff -Nru golang-github-containers-storage-1.24.8+dfsg1/debian/changelog 
golang-github-containers-storage-1.24.8+dfsg1/debian/changelog
--- golang-github-containers-storage-1.24.8+dfsg1/debian/changelog  
2021-02-21 14:40:55.0 -0500
+++ golang-github-containers-storage-1.24.8+dfsg1/debian/changelog  
2022-12-28 21:39:17.0 -0500
@@ -1,3 +1,12 @@
+golang-github-containers-storage (1.24.8+dfsg1-1+deb11u1) bullseye; 
urgency=medium
+
+  [ Vignesh Raman ]
+  * prereq to fix CVE-2022-1227: pkg: idtools: export RawTo{Container,Host}:
+makes previously internal functions publicly accessible, which is being
+used by later versions of golang-github-containers-psgo.
+
+ -- Reinhard Tartler   Wed, 28 Dec 2022 21:39:17 -0500
+
 golang-github-containers-storage (1.24.8+dfsg1-1) unstable; urgency=medium
 
   * New upstream release, focused on targetted bugfixes for podman 3.0
diff -Nru 
golang-github-containers-storage-1.24.8+dfsg1/debian/patches/0001-pkg-idtools-export-RawTo-Container-Host.patch
 
golang-github-containers-storage-1.24.8+dfsg1/debian/patches/0001-pkg-idtools-export-RawTo-Container-Host.patch
--- 
golang-github-containers-storage-1.24.8+dfsg1/debian/patches/0001-pkg-idtools-export-RawTo-Container-Host.patch
 1969-12-31 19:00:00.0 -0500
+++ 
golang-github-containers-storage-1.24.8+dfsg1/debian/patches/0001-pkg-idtools-export-RawTo-Container-Host.patch
 2022-12-28 21:39:17.0 -0500
@@ -0,0 +1,111 @@
+From 3da85a122411a57b5a65dc243ae56f89d7fd2564 Mon Sep 17 00:00:00 2001
+From: Aleksa Sarai 
+Date: Wed, 12 Jan 2022 12:56:56 +1100
+Subject: [PATCH 1/4] pkg: idtools: export RawTo{Container,Host}
+
+While the IDMapping methods are preferable for most users, sometimes it
+is necessary to map a single ID using a given mapping. In particular
+this is needed for psgo to be able to map the user and group entries in
+/proc/$pid/status using the user namespace of the target process.
+
+Required to resolve CVE-2022-1227.
+
+Signed-off-by: Aleksa Sarai 
+Backported-by: Valentin Rothberg 
+---
+ pkg/idtools/idtools.go | 36 ++--
+ 1 file changed, 22 insertions(+), 14 deletions(-)
+
+diff --git a/pkg/idtools/idtools.go b/pkg/idtools/idtools.go
+index 83bc8c34f..d3d56066e 100644
+--- a/pkg/idtools/idtools.go
 b/pkg/idtools/idtools.go
+@@ -82,7 +82,7 @@ func GetRootUIDGID(uidMap, gidMap []IDMap) (int, int, error) 
{
+   if len(uidMap) == 1 && uidMap[0].Size == 1 {
+   uid = uidMap[0].HostID
+   } else {
+-  uid, err = toHost(0, uidMap)
++  uid, err = RawToHost(0, uidMap)
+   if err != nil {
+   return -1, -1, err
+   }
+@@ -90,7 +90,7 @@ func GetRootUIDGID(uidMap, gidMap []IDMap) (int, int, error) 
{
+   if len(gidMap) == 1 && gidMap[0].Size == 1 {
+   gid = gidMap[0].HostID
+   } else {
+-  gid, err = toHost(0, gidMap)
++  gid, err = RawToHost(0, gidMap)
+   if err != nil {
+   return -1, -1, err
+   }
+@@ -98,10 +98,14 @@ func GetRootUIDGID(uidMap, gidMap []IDMap) (int, int, 
error) {
+   return uid, gid, nil
+ }
+ 
+-// toContainer takes an id mapping, and uses it to translate a
+-// host ID to the remapped ID. If no map is provided, then the translation
+-// assumes a 1-to-1 mapping and returns the passed in id
+-func toContainer(hostID int, idMap []IDMap) (int, error) {
++// RawToContainer takes an id mapping, and uses it to translate a host ID to
++// the remapped ID. If no map is provided, then the translation assumes a
++// 1-to-1 map

Bug#1027257: bullseye-pu: package golang-github-containers-storage/1.24.8+dfsg1-2~deb11u1

[Reinhard Tartler]

On 4/1/23 3:51 PM, Adam D. Barratt wrote:

Control: tags -1 + moreinfo

Apologies for the delay in getting back to you on this.

On Wed, 2022-12-28 at 22:26 -0500, Reinhard Tartler wrote:

In order to fix CVE-2022-1227, an update to golang-github-containers-
psgo
is needed, more specifically,
https://github.com/containers/psgo/pull/92

That patch introduces a dependency on golang-github-containers-
storage, and uses
the helper functions RawTo{Container,Host} which are introduced with
this patch.


[...]

The code changes adds a helper function that isn't used otherwise
yet.


Looking at the diff, it appears that what it actually does is rename
two existing helper functions, with no functional change to either. Am
I missing something?


You are correct. The patch renames the helper functions to an Uppercase 
spelling.
This exposes the function to other packages, which is being used in the patch
to fix CVE-2022-1227.

I would recommend approving this code change.


+golang-github-containers-storage (1.24.8+dfsg1-2~deb11u1) bullseye;
urgency=medium


Given what I can see of the package's upload history, the version
should rather be 1.24.8+dfsg1-1+deb11u1.


Will do!
-rt

Bug#867523: ITP: golang-github-pkg-browser -- Package browser provides helpers to open files, readers, and urls in a browser window.

[Reinhard Tartler]

Hi Patrick,

I overlooked that you worked on this package in 2017. It appears that it
was never uploaded to Debian. Do you remember why? Was it rejected from
ftp-master for some reason or something?

I took the liberty of pushing my packaging attempt to salsa. Let me know if
you are still interested in this package and let me know what you think.

Best,
-rt

On Thu, Jul 6, 2017 at 9:42 PM root  wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Patrick O'Doherty 
>
> * Package name: golang-github-pkg-browser
>   Version : 0.0~git20170505.0.c90ca0c-1
>   Upstream Author :
> * URL : https://github.com/pkg/browser
> * License : BSD-2-clause
>   Programming Lang: Go
>   Description : provides helpers to open files, readers, and urls in a
> browser window.
>
>  Package browser provides helpers to open files, readers, and URLs in a
> browser window.
>
>

-- 
regards,
Reinhard

Bug#1033736: ITP: golang-github-pkg-browser -- Package browser provides helpers to open files, readers, and urls in a browser window.

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-pkg-browser
  Version : 0.0~git20210911.681adbf-1
  Upstream Author : 
* URL : https://github.com/pkg/browser
* License : BSD-2-clause
  Programming Lang: Go
  Description : Package browser provides helpers to open files, readers, 
and urls in a browser window.

This golang helper library provides helpers to open files, readers, and
urls in a browser window. It is a build dependency of
golang-github-sigstore-sigstore, cf. #1029170

Bug#1033735: ITP: golang-github-jellydator-ttlcache -- An in-memory cache with item expiration and generics

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-jellydator-ttlcache
  Version : 3.0.1-1
  Upstream Author : Jellydator
* URL : https://github.com/jellydator/ttlcache
* License : Expat
  Programming Lang: Go
  Description : An in-memory cache with item expiration and generics

This is a build dependency of golang-github-sigstore-sigstore, cf. #1029170

Bug#1029170: ITP: golang-github-sigstore-sigstore -- Common go library shared across sigstore services and clients

[Reinhard Tartler]

Sounds good.

I'm happy to take on the easier dependencies, such as pkg/browser or
jellydator/ttlcache.

But the dependency on boulder is giving me a massive headache. It is really
unfortunate that they chose to use such a heavy dependency for a rather
simple task (goodkey). What are your thoughts on resolving this?

-rt

On Sun, Feb 5, 2023 at 3:30 PM Leo Antunes  wrote:

> Hi Reinhard,
>
> It seems I underestimated the work and overestimated by free time: we need
> some bumps for deps (e.g. golang-github-azure-azure-sdk-for-go-dev) and
> maybe some patching to get rid of other deps (e.g.
> github.com/letsencrypt/boulder), if we can manage that.
> OTOH, I see you already took care of #1030555 and #1030557! That's great!
> :)
>
> Cheers
> Leo
>
>
> --- Original Message ---
> On Thursday, February 2nd, 2023 at 12:33, Reinhard Tartler <
> siret...@gmail.com> wrote:
>
>
> > seems https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022937 was
> accepted. Any update on sigstore packaging?
>
>
>

-- 
regards,
Reinhard

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

[Reinhard Tartler]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: con...@packages.debian.org, Dan Nicholson 
Control: affects -1 + src:conmon


[ Reason ]

conmon 2.0.25 contains a bug where the container will hang when there
is lots of terminal output. You can easily reproduce like so:

podman run -it --rm debian:latest
find /

This is fixed in 2.0.26 with
https://github.com/containers/conmon/commit/2b873145a85a212f703c9c00db13717ab0204318.
See https://github.com/containers/conmon/issues/236.

[ Impact ]
podman hangs with the testcase above

[ Tests ]
no automated test case

[ Risks ]
this is a one-line code-change backported from upstream

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]

diff --git a/src/conn_sock.c b/src/conn_sock.c
index e569113f..02aee701 100644
--- a/src/conn_sock.c
+++ b/src/conn_sock.c
@@ -280,7 +280,6 @@ static gboolean attach_cb(int fd, G_GNUC_UNUSED 
GIOCondition condition, gpointer
pexit("Failed to allocate memory");
}
init_remote_sock(remote_sock, srcsock);
-   g_unix_set_fd_nonblocking(new_fd, TRUE, NULL);
remote_sock->fd = new_fd;
g_unix_fd_add(remote_sock->fd, G_IO_IN | G_IO_HUP | G_IO_ERR, 
remote_sock_cb, remote_sock);
g_ptr_array_add(remote_sock->dest->readers, remote_sock);

[ Other info ]
See https://github.com/containers/conmon/issues/236 for the full investigation
diff -Nru conmon-2.0.25+ds1/debian/changelog conmon-2.0.25+ds1/debian/changelog
--- conmon-2.0.25+ds1/debian/changelog  2021-07-14 11:46:07.0 -0600
+++ conmon-2.0.25+ds1/debian/changelog  2022-06-29 09:35:38.0 -0600
@@ -1,3 +1,10 @@
+conmon (2.0.25+ds1-1.1+deb11u1) bullseye; urgency=medium
+
+  * Backport upstream fix to not hang when forwarding container
+stdout/stderr with lots of output. (Closes: #1014030)
+
+ -- Dan Nicholson   Wed, 29 Jun 2022 09:35:38 -0600
+
 conmon (2.0.25+ds1-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru 
conmon-2.0.25+ds1/debian/patches/0002-conn_sock-do-not-fail-on-EAGAIN.patch 
conmon-2.0.25+ds1/debian/patches/0002-conn_sock-do-not-fail-on-EAGAIN.patch
--- conmon-2.0.25+ds1/debian/patches/0002-conn_sock-do-not-fail-on-EAGAIN.patch 
1969-12-31 17:00:00.0 -0700
+++ conmon-2.0.25+ds1/debian/patches/0002-conn_sock-do-not-fail-on-EAGAIN.patch 
2022-06-29 09:33:10.0 -0600
@@ -0,0 +1,37 @@
+From 2b873145a85a212f703c9c00db13717ab0204318 Mon Sep 17 00:00:00 2001
+From: Giuseppe Scrivano 
+Date: Tue, 2 Feb 2021 11:35:39 +0100
+Subject: [PATCH] conn_sock: do not fail on EAGAIN
+
+commit 6287bd884d9bf29e76ac877e0c7e6aad04bc24a4 introduced the
+regression.
+
+writes to the attached sockets must be blocking, otherwise the
+write_back_to_remote_consoles() shutdowns the socket when write fails
+with EAGAIN.
+
+I've verified the original issue fixed with commit 62887bd is not
+reintroduced with this patch.
+
+Closes: https://github.com/containers/conmon/issues/236
+
+Signed-off-by: Giuseppe Scrivano 
+---
+ src/conn_sock.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/src/conn_sock.c b/src/conn_sock.c
+index e569113..02aee70 100644
+--- a/src/conn_sock.c
 b/src/conn_sock.c
+@@ -280,7 +280,6 @@ static gboolean attach_cb(int fd, G_GNUC_UNUSED 
GIOCondition condition, gpointer
+   pexit("Failed to allocate memory");
+   }
+   init_remote_sock(remote_sock, srcsock);
+-  g_unix_set_fd_nonblocking(new_fd, TRUE, NULL);
+   remote_sock->fd = new_fd;
+   g_unix_fd_add(remote_sock->fd, G_IO_IN | G_IO_HUP | G_IO_ERR, 
remote_sock_cb, remote_sock);
+   g_ptr_array_add(remote_sock->dest->readers, remote_sock);
+-- 
+2.30.2
+
diff -Nru conmon-2.0.25+ds1/debian/patches/series 
conmon-2.0.25+ds1/debian/patches/series
--- conmon-2.0.25+ds1/debian/patches/series 2021-07-14 11:46:07.0 
-0600
+++ conmon-2.0.25+ds1/debian/patches/series 2022-06-29 09:33:10.0 
-0600
@@ -1 +1,2 @@
 0001-Reset-OOM-score-back-to-0-for-container-runtime.patch
+0002-conn_sock-do-not-fail-on-EAGAIN.patch

Bug#1030557: ITP: golang-github-theupdateframework-go-tuf -- A framework for securing software in golang (library)

[Reinhard Tartler]

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

* Package name: golang-github-theupdateframework-go-tuf
  Version : 0.5.2
  Upstream Contact: https://github.com/theupdateframework/go-tuf
* URL : https://github.com/theupdateframework/go-tuf
* License : BSD-3-clause
  Programming Lang: golang
  Description : A framework for securing software in golang  (library)

The Update Framework (TUF) helps developers maintain the security of software
update systems, providing protection even against attackers that compromise
the repository or signing keys. TUF provides a flexible framework and
specification that developers can adopt into any software update system.

Bug#1030555: ITP: golang-github-secure-systems-lab-go-securesystemslib -- Cryptographic and general-purpose routines for Golang Secure Systems Lab projects at NYU

[Reinhard Tartler]

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

* Package name: golang-github-secure-systems-lab-go-securesystemslib
  Version : 0.4.0
  Upstream Contact: https://github.com/secure-systems-lab/go-securesystemslib
* URL : https://github.com/secure-systems-lab/go-securesystemslib
* License : Expat
  Programming Lang: Golang
  Description : Cryptographic and general-purpose routines for Golang 
Secure Systems Lab projects at NYU


Description: Cryptographic and general-purpose routines for Golang Secure 
Systems Lab projects at NYU (library)
 A library that provides cryptographic and general-purpose functions for
 Go Secure Systems Lab projects at NYU.

I plan to maintain this library under the pkg-golang umbrella.

It is one of the missing dependencies for sigstore

Bug#1029170: ITP: golang-github-sigstore-sigstore -- Common go library shared across sigstore services and clients

[Reinhard Tartler]

seems https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022937 was
accepted. Any update on sigstore packaging?

On Fri, Jan 20, 2023 at 9:47 AM Reinhard Tartler  wrote:

> Awesome, thanks for the update!
>
> Skimming over the sources of sigstore, it seems to me that the awk-sdk
> might be easy to disable with minor surgery. Would you be open to uploading
> a sigstore package to NEW with the aws functionality disabled and re-enable
> it as soon as the awk package becomes available in Debian?
>
> -rt
>
> On Fri, Jan 20, 2023 at 7:30 AM Leo Antunes  wrote:
>
>> Hi Reinhard!
>>
>> I think this changed a bit in the meantime: now the sigstore project has
>> mostly shared lib code, while the individual commands (rekor, fulcio,
>> gitsign, etc) are all in separate repos. So I expect this library to not be
>> THAT difficult to package (the next one on my list is rekor - see #990249
>> - which will probably require more work).
>> As soon as #1022937 is done (waiting in NEW since 2 months), I expect
>> sigstore to be a quick follow-up.
>> However, I'd gladly take an extra pair of eyes on the package, so I can
>> ping you as soon as I have something that builds.
>>
>>
>> Thanks,
>> Leo Antunes
>> --- Original Message ---
>> On Thursday, January 19th, 2023 at 09:37, Reinhard Tartler <
>> siret...@gmail.com> wrote:
>>
>> Hi Leo,
>>
>> Thank you so much for your interest in packaging this! -- I've noticed
>> that it is a dependency of containers/image for image signing, and have
>> looked at this package before. Unfortunately, I got intimidated with the
>> sheer number of unpackaged dependencies that it requires. Maybe this has
>> improved since the last time I looked at it? In any case, I've decided to
>> patch the source to disable signing functionality to avoid requiring code
>> from sigstore, which is of course very unfortunate.
>>
>> Let me know if you could use another set of eyeballs or help with this
>> package. It surely seems intimidating (at least to me).
>>
>> best,
>> -rt
>>
>> On Wed, Jan 18, 2023 at 3:21 PM Leo Antunes  wrote:
>>
>>> Package: wnpp
>>> Severity: wishlist
>>> Owner: Leo Antunes 
>>>
>>> * Package name : golang-github-sigstore-sigstore
>>> Version : 1.5.1-1
>>> Upstream Author : The Sigstore Authors 
>>> * URL : https://github.com/sigstore/sigstore
>>> * License : Apache-2.0
>>> Programming Lang: Go
>>> Description : Common go library shared across sigstore services and
>>> clients
>>>
>>> sigstore/sigstore contains common Sigstore code: that is, code shared
>>> by infrastructure (e.g. Fulcio and Rekor) and Go language clients (e.g.
>>> Cosign and Gitsign.
>>>
>>>
>>
>> --
>> regards,
>> Reinhard
>>
>>
>>
>
> --
> regards,
> Reinhard
>


-- 
regards,
Reinhard

Bug#1029170: ITP: golang-github-sigstore-sigstore -- Common go library shared across sigstore services and clients

[Reinhard Tartler]

Awesome, thanks for the update!

Skimming over the sources of sigstore, it seems to me that the awk-sdk
might be easy to disable with minor surgery. Would you be open to uploading
a sigstore package to NEW with the aws functionality disabled and re-enable
it as soon as the awk package becomes available in Debian?

-rt

On Fri, Jan 20, 2023 at 7:30 AM Leo Antunes  wrote:

> Hi Reinhard!
>
> I think this changed a bit in the meantime: now the sigstore project has
> mostly shared lib code, while the individual commands (rekor, fulcio,
> gitsign, etc) are all in separate repos. So I expect this library to not be
> THAT difficult to package (the next one on my list is rekor - see #990249
> - which will probably require more work).
> As soon as #1022937 is done (waiting in NEW since 2 months), I expect
> sigstore to be a quick follow-up.
> However, I'd gladly take an extra pair of eyes on the package, so I can
> ping you as soon as I have something that builds.
>
>
> Thanks,
> Leo Antunes
> --- Original Message ---
> On Thursday, January 19th, 2023 at 09:37, Reinhard Tartler <
> siret...@gmail.com> wrote:
>
> Hi Leo,
>
> Thank you so much for your interest in packaging this! -- I've noticed
> that it is a dependency of containers/image for image signing, and have
> looked at this package before. Unfortunately, I got intimidated with the
> sheer number of unpackaged dependencies that it requires. Maybe this has
> improved since the last time I looked at it? In any case, I've decided to
> patch the source to disable signing functionality to avoid requiring code
> from sigstore, which is of course very unfortunate.
>
> Let me know if you could use another set of eyeballs or help with this
> package. It surely seems intimidating (at least to me).
>
> best,
> -rt
>
> On Wed, Jan 18, 2023 at 3:21 PM Leo Antunes  wrote:
>
>> Package: wnpp
>> Severity: wishlist
>> Owner: Leo Antunes 
>>
>> * Package name : golang-github-sigstore-sigstore
>> Version : 1.5.1-1
>> Upstream Author : The Sigstore Authors 
>> * URL : https://github.com/sigstore/sigstore
>> * License : Apache-2.0
>> Programming Lang: Go
>> Description : Common go library shared across sigstore services and
>> clients
>>
>> sigstore/sigstore contains common Sigstore code: that is, code shared
>> by infrastructure (e.g. Fulcio and Rekor) and Go language clients (e.g.
>> Cosign and Gitsign.
>>
>>
>
> --
> regards,
> Reinhard
>
>
>

-- 
regards,
Reinhard

Bug#1029170: ITP: golang-github-sigstore-sigstore -- Common go library shared across sigstore services and clients

[Reinhard Tartler]

Hi Leo,

Thank you so much for your interest in packaging this! -- I've noticed that
it is a dependency of containers/image for image signing, and have looked
at this package before. Unfortunately, I got intimidated with the sheer
number of unpackaged dependencies that it requires. Maybe this has improved
since the last time I looked at it? In any case, I've decided to patch the
source to disable signing functionality to avoid requiring code from
sigstore, which is of course very unfortunate.

Let me know if you could use another set of eyeballs or help with this
package. It surely seems intimidating (at least to me).

best,
-rt

On Wed, Jan 18, 2023 at 3:21 PM Leo Antunes  wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Leo Antunes 
>
> * Package name: golang-github-sigstore-sigstore
>   Version : 1.5.1-1
>   Upstream Author : The Sigstore Authors 
> * URL : https://github.com/sigstore/sigstore
> * License : Apache-2.0
>   Programming Lang: Go
>   Description : Common go library shared across sigstore services and
> clients
>
>  sigstore/sigstore contains common Sigstore code: that is, code shared
>  by infrastructure (e.g. Fulcio and Rekor) and Go language clients (e.g.
>  Cosign and Gitsign.
>
>

-- 
regards,
Reinhard

Bug#1028810: aspectc++: FTBFS: ld: cannot find -lPolly: No such file or directory

[Reinhard Tartler]

Control: reassign -1 llvm-14
Control: affects -1 aspectc++

Hi Lucas,

thanks for filing this report.

My understanding of this issue is that a recent change in llvm 14 leads to the 
list of libraries listed by `llvm-config-14 --libs` to be incomplete. I think 
that this build would succeed if it included -lPolly.

You can see how aspectc++ invokes llvm-config here: 
https://salsa.debian.org/debian/aspectc/-/blob/791f390f845b2fafd19ff0c648618e8e14cee726/AspectC++/Makefile#L79

Dear LLVM maintainers, does this make sense to you?

-rt

On 1/14/23 7:30 AM, Lucas Nussbaum wrote:

Source: aspectc++
Version: 1:2.3+git20221129-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230113 ftbfs-bookworm

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):

make[2]: Entering directory '/<>/AspectC++/ACModel'
---
Making ACModel library for TARGET=linux-release
Compiler = g++ -DNDEBUG  -std=gnu++11 -I../../Puma/extern `xml2-config 
--cflags`  -O2 -g -Wall -pipe -Wno-deprecated-declarations -Wall -pipe 
-Wno-deprecated-declarations
---
Making dependency file ObjFiles/linux-release/Elements.o.
---
Making dependency file ObjFiles/linux-release/MatchExpr.o.
Making dependency file DepFiles/linux-release/ACConfig.d.
Making dependency file ObjFiles/linux-release/MatchName.o.
Making dependency file DepFiles/linux-release/ACProject.d.
Making AspectC++ for TARGET=linux-release
Making dependency file DepFiles/linux-release/AdviceInfo.d.
Making dependency file ObjFiles/linux-release/MatchTemplateArg.o.
   Compiler = g++ -DNDEBUG  -std=gnu++11 -I../Puma/extern -I../Puma/include 
-I/usr/include/libxml2  -I/usr/lib/llvm-14/include -D_GNU_SOURCE 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-DFRONTEND_CLANG -O2 -g -Wall -pipe -Wno-deprecated-declarations  -fno-rtti 
-Wno-strict-aliasing  -std=gnu++14
   Linker   = g++ -O2 -g -Wall -pipe -Wno-deprecated-declarations  -fno-rtti 
-Wno-strict-aliasing  -std=gnu++14   -L../Puma/lib/linux-release 
-lMiniPuma  -lxml2  -lclangRewriteFrontend -lclangRewrite -lclangFrontend 
-lclangSerialization -lclangDriver -lclangParse -lclangSema -lclangAnalysis 
-lclangEdit -lclangAST -lclangLex -lclangBasic -lLLVMAsmParser -lLLVMMCParser 
-lLLVMBitReader -lLLVMTransformUtils -lLLVMCore -lLLVMMC -lLLVMOption -lLLVMSupport 
-Wl,--as-needed -latomic -Wl,--no-as-needed -Xlinker 
--wrap=_ZN5clang4Sema19canSkipFunctionBodyEPNS_4DeclE -Xlinker 
--wrap=_ZN5clang4Sema21ProcessStmtAttributesEPNS_4StmtERKNS_25ParsedAttributesWithRangeERN4llvm15SmallVectorImplIPKNS_4AttrEEE
 -L/usr/lib/llvm-14/lib  -lLLVMWindowsManifest -lLLVMXRay -lLLVMLibDriver 
-lLLVMDlltoolDriver -lLLVMCoverage -lLLVMLineEditor -lLLVMM68kDisassembler 
-lLLVMM68kAsmParser -lLLVMM68kCodeGen -lLLVMM68kDesc -lLLVMM68kInfo 
-lLLVMXCoreDisassembler -lLLVMXCoreCodeGen -lLLVMXCoreDesc -lLLVMXCoreInfo 
-lLLVMX86TargetMCA -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen 
-lLLVMX86Desc -lLLVMX86Info -lLLVMWebAssemblyDisassembler -lLLVMWebAssemblyAsmParser 
-lLLVMWebAssemblyCodeGen -lLLVMWebAssemblyDesc -lLLVMWebAssemblyUtils 
-lLLVMWebAssemblyInfo -lLLVMVEDisassembler -lLLVMVEAsmParser -lLLVMVECodeGen 
-lLLVMVEDesc -lLLVMVEInfo -lLLVMSystemZDisassembler -lLLVMSystemZAsmParser 
-lLLVMSystemZCodeGen -lLLVMSystemZDesc -lLLVMSystemZInfo -lLLVMSparcDisassembler 
-lLLVMSparcAsmParser -lLLVMSparcCodeGen -lLLVMSparcDesc -lLLVMSparcInfo 
-lLLVMRISCVDisassembler -lLLVMRISCVAsmParser -lLLVMRISCVCodeGen -lLLVMRISCVDesc 
-lLLVMRISCVInfo -lLLVMPowerPCDisassembler -lLLVMPowerPCAsmParser -lLLVMPowerPCCodeGen 
-lLLVMPowerPCDesc -lLLVMPowerPCInfo -lLLVMNVPTXCodeGen -lLLVMNVPTXDesc 
-lLLVMNVPTXInfo -lLLVMMSP430Disassembler -lLLVMMSP430AsmParser -lLLVMMSP430CodeGen 
-lLLVMMSP430Desc -lLLVMMSP430Info -lLLVMMipsDisassembler -lLLVMMipsAsmParser 
-lLLVMMipsCodeGen -lLLVMMipsDesc -lLLVMMipsInfo -lLLVMLanaiDisassembler 
-lLLVMLanaiCodeGen -lLLVMLanaiAsmParser -lLLVMLanaiDesc -lLLVMLanaiInfo 
-lLLVMHexagonDisassembler -lLLVMHexagonCodeGen -lLLVMHexagonAsmParser 
-lLLVMHexagonDesc -lLLVMHexagonInfo -lLLVMBPFDisassembler -lLLVMBPFAsmParser 
-lLLVMBPFCodeGen -lLLVMBPFDesc -lLLVMBPFInfo -lLLVMAVRDisassembler -lLLVMAVRAsmParser 
-lLLVMAVRCodeGen -lLLVMAVRDesc -lLLVMAVRInfo -lLLVMARMDisassembler -lLLVMARMAsmParser 
-lLLVMARMCodeGen -lLLVMARMDesc -lLLVMARMUtils -lLLVMARMInfo -lLLVMAMDGPUTargetMCA 
-lLLVMAMDGPUDisassembler -lLLVMAMDGPUAsmParser -lLLVMAMDGPUCodeGen -lLLVMAMDGPUDesc 
-lLLVMAMDGPUUtils -lLLVMAMDGPUInfo -lLLVMAArch64Disassembler -lLLVMAArch64AsmParser 
-lLLVMAArch64CodeGen -lLLVMAArch64Desc -lLLVMAArch64Utils -lLLVMAArch64Info 
-lLLVMPerfJITEvents -lLLVMOrcJIT -lLLVMMCJIT -lLLVMJITLink -lLLVMInterpreter 
-lLLVMExecutionEngine -lLLVMRuntimeDyld -lLLVMOrcTargetProcess -lLLVMOrcShared 
-lLLVMDWP -lLLVMSymbolize -lLLVMDebugInfoPDB -lLLVMDebugInfoGSYM -lLLVMOption 
-lLLVMObjectYAML -lLLVMMCA -lLLVMMCDisassembler -lLLVMLTO