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 

Bug#1028648: aardvark-dns: please build-depend explicitly on required version of clap.

[Reinhard Tartler]

Hi Peter,

On 1/14/23 4:03 AM, Peter Green wrote:

Package: aardvark-dns

aardvark-dns build-depends on librust-clap+derive-dev, this is a virtual package
provided by both librust-clap-dev and librust-clap-3-dev, it is also a cruft
physical package which I would like to see decrufted as I belive is it the cause
of spurious puiparts regressions in the testing migration of rust-clap.

Your cargo dependency on clap is versioned as 3.2, per semver this allows any
3.x version greater than 3.2. Therefore your build-dependency should be on
librust-clap-3+derive-dev (>= 3.2).

Fortunately clap 3 is currently pulled in indirectly, so right now this can't
cause a FTBFS, still it is something I would like to see fixed.

A debdiff updating the build-dependency is attatched, if I get no response
I will likely NMU this in a week or so.


debdiff looks fine, I plan on uploading it to unstable as soon as the current
version migrates. Thanks for your understanding and downgrading this to 
'important',
version 1.4.0-2 fixes a critical functionality update.

Thanks for this bug report and the provided fix!

-rt

Bug#1028401: closed by Debian FTP Masters (Bug#1028401: Removed package(s) from unstable)

[Reinhard Tartler]

reopen 1028401
retitle 1028401 RM: rust-trust-dns-proto [mips64el mips mipsel ppc64el s390x] 
-- ROM; defacto architecture specific
thanks

On 1/10/23 4:24 PM, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the ftp.debian.org package:

#1028401: RM: rust-trust-dns-proto [mips64el mips ppc64el s390x] -- ROM; 
defacto architecture specific

It has been closed by Debian FTP Masters .



Thank you for your prompt response. Turns out, I forgot to add 'mispel' to the 
list.

I have to bug you to also remove the remaining build on mipsel to allow 
migration to testing:


$ rmadison librust-trust-dns-proto-dev
librust-trust-dns-proto-dev | 0.21.2-6  | testing | amd64, arm64, 
armel, armhf, i386
librust-trust-dns-proto-dev | 0.22.0-1  | unstable| mipsel
librust-trust-dns-proto-dev | 0.22.0-2  | buildd-unstable | amd64, arm64, 
armel, armhf, i386
librust-trust-dns-proto-dev | 0.22.0-2  | unstable| amd64, arm64, 
armel, armhf, i386


Thank you for bearing with me.

best,
-rt

Bug#1028401: RM: rust-trust-dns-proto [mips64el mips ppc64el s390x] -- ROM; defacto architecture specific

[Reinhard Tartler]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: rust-trust-dns-pr...@packages.debian.org, Peter Green 

Control: affects -1 + src:rust-trust-dns-proto

Please remove rust-trust-dns-proto on [mips64el mips ppc64el s390x] to allow 
the package
to migrate to testing.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026769 for additional 
context.

Thank you!

Bug#1026588: Fix pending in the NEW queue

[Reinhard Tartler]

Control: tag 1026588 pending
Control: block 1026598 by 1026588

I really should have mentioned this bug in debian/changelog before
uploading. It is currently pending at
https://ftp-master.debian.org/new/rust-trust-dns-server_0.22.0-1.html

Dear ftp-master, happy holidays!

Any chance you could fast-track this package so that I can fix 2 RC bugs?
I'm concerned that if not fixed in time, aardvark-dns would be removed from
testing, which would break podman and friends.

Thanks in advance!

-- 
regards,
Reinhard

Bug#1027258: bullseye-pu: package golang-github-containers-psgo/1.5.2-2~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-p...@packages.debian.org, 
siret...@tauware.de, siret...@gmail.com, Vignesh Raman 
vignesh.ra...@collabora.com
Control: affects -1 + src:golang-github-containers-psgo


[ Reason ]

Backport for CVE-2022-1227, taken from 
https://github.com/containers/psgo/pull/92

This prevents an exploit when running 'podman top'

[ Impact ]


[ Tests ]
No new test is added. The code change is rather small and straight-forward to
review. It required small changes to apply to this older version.

[ Risks ]
I determined that the code change and adaptions to version 1.5.2 is easier to
review than updating containers-psgo to upstream version 1.7.2, which would
be closer to how upstream or Fedora/RedHat would recommend to address this 
issue.

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

[ Changes ]

diff --git a/debian/changelog b/debian/changelog
index a1f0d96..0448fdf 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+golang-github-containers-psgo (1.5.2-2~deb11u1) bullseye; urgency=medium
+
+  * CVE-2022-1227: do not join the process user namespace
+
+ -- Reinhard Tartler   Wed, 28 Dec 2022 21:21:57 -0500
+
 golang-github-containers-psgo (1.5.2-1) unstable; urgency=medium

   * Team upload
diff --git a/debian/control b/debian/control
index 5a52891..ba4c8e5 100644
--- a/debian/control
+++ b/debian/control
@@ -10,6 +10,7 @@ Build-Depends:
  dh-golang,
 Build-Depends-Indep:
  golang-any,
+ golang-github-containers-storage-dev (>= 1.24.8+dfsg1-2~deb11u1),
  golang-github-opencontainers-runc-dev,
  golang-github-pkg-errors-dev,
  golang-github-sirupsen-logrus-dev,
diff --git a/debian/patches/CVE-2022-1227.patch 
b/debian/patches/CVE-2022-1227.patch
new file mode 100644
index 000..991a7c5
--- /dev/null
+++ b/debian/patches/CVE-2022-1227.patch
@@ -0,0 +1,279 @@
+commit 3ae3044916481f5c001f64a9d26110b878a676e0 (github/v1.7.1-fedora)
+Author: Aleksa Sarai 
+Date:   Wed Jan 12 01:01:30 2022 +1100
+
+internal: proc: do not join the process user namespace
+
+The only reason we joined the process user namespace was to map a
+handful of fields into the same usernamepsace as that process. This
+procedure can be implemented entirely in Go without having to run code
+inside the container.
+
+In addition, since psgo is used inside "podman top", we were actually
+executing the nsenter binary *from the container* without all of the
+container's security profiles applied. At the very least this would
+allow a container process to return bad data to psgo (possibly confusing
+management scripts using psgo) and at the very worst it would allow the
+container process to escalate privileges by getting podman to execute
+code without all of the container security profiles applied.
+
+Fixes: CVE-2022-1227
+
+Signed-off-by: Aleksa Sarai 
+Backported-by: Valentin Rothberg 
+Signed-off-by: Valentin Rothberg 
+
+Index: golang-github-containers-psgo/internal/proc/ns.go
+===
+--- golang-github-containers-psgo.orig/internal/proc/ns.go
 golang-github-containers-psgo/internal/proc/ns.go
+@@ -21,14 +21,9 @@ import (
+   "os"
+
+   "github.com/pkg/errors"
++  "github.com/containers/storage/pkg/idtools"
+ )
+
+-type IDMap struct {
+-  ContainerID int
+-  HostID  int
+-  Sizeint
+-}
+-
+ // ParsePIDNamespace returns the content of /proc/$pid/ns/pid.
+ func ParsePIDNamespace(pid string) (string, error) {
+   pidNS, err := os.Readlink(fmt.Sprintf("/proc/%s/ns/pid", pid))
+@@ -48,14 +43,14 @@ func ParseUserNamespace(pid string) (str
+ }
+
+ // ReadMappings reads the user namespace mappings at the specified path
+-func ReadMappings(path string) ([]IDMap, error) {
++func ReadMappings(path string) ([]idtools.IDMap, error) {
+   file, err := os.Open(path)
+   if err != nil {
+   return nil, errors.Wrapf(err, "cannot open %s", path)
+   }
+   defer file.Close()
+
+-  mappings := []IDMap{}
++  var mappings []idtools.IDMap
+
+   buf := bufio.NewReader(file)
+   for {
+@@ -70,10 +65,10 @@ func ReadMappings(path string) ([]IDMap,
+   return mappings, nil
+   }
+
+-  containerID, hostID, size := 0, 0, 0
++  var containerID, hostID, size int
+   if _, err := fmt.Sscanf(string(line), "%d %d %d", , 
, ); err != nil {
+   return nil, errors.Wrapf(err, "cannot parse %s", 
string(line))
+   }
+-  mappings = append(mappings, IDM

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

[Reinhard Tartler]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: golang-github-containers-stor...@packages.debian.org, 
siret...@tauware.de, siret...@gmail.com, Vignesh Raman 
vignesh.ra...@collabora.com
Control: affects -1 + src:golang-github-containers-storage


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

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

[ Impact ]

[ Tests ]
No new tests are added. The patch was taken from upstream and required
little modificaiton to apply.

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

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

[ Changes ]
diff --git a/debian/changelog b/debian/changelog
index 837efeeb1..640a90134 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+golang-github-containers-storage (1.24.8+dfsg1-2~deb11u1) bullseye; 
urgency=medium
+
+  [ Vignesh Raman ]
+  * prereq to fix CVE-2022-1227: pkg: idtools: export RawTo{Container,Host}
+
+ -- Reinhard Tartler   Wed, 28 Dec 2022 21:39:17 -0500
+
 golang-github-containers-storage (1.24.8+dfsg1-1) unstable; urgency=medium

   * New upstream release, focused on targetted bugfixes for podman 3.0
diff --git a/debian/patches/0001-pkg-idtools-export-RawTo-Container-Host.patch 
b/debian/patches/0001-pkg-idtools-export-RawTo-Container-Host.patch
new file mode 100644
index 0..d00cbd0e9
--- /dev/null
+++ b/debian/patches/0001-pkg-idtools-export-RawTo-Container-Host.patch
@@ -0,0 +1,111 @@
+From 3da85a122411a57b5a65dc243ae56f89d7fd2564 Mon Sep 17 00:00:00 2001
+From: Aleksa Sarai 
+Date: Wed, 12 Jan 2022 12:56:56 +1100
+Subject: [PATCH 1/4] pkg: idtools: export RawTo{Container,Host}
+
+While the IDMapping methods are preferable for most users, sometimes it
+is necessary to map a single ID using a given mapping. In particular
+this is needed for psgo to be able to map the user and group entries in
+/proc/$pid/status using the user namespace of the target process.
+
+Required to resolve CVE-2022-1227.
+
+Signed-off-by: Aleksa Sarai 
+Backported-by: Valentin Rothberg 
+---
+ pkg/idtools/idtools.go | 36 ++--
+ 1 file changed, 22 insertions(+), 14 deletions(-)
+
+diff --git a/pkg/idtools/idtools.go b/pkg/idtools/idtools.go
+index 83bc8c34f..d3d56066e 100644
+--- a/pkg/idtools/idtools.go
 b/pkg/idtools/idtools.go
+@@ -82,7 +82,7 @@ func GetRootUIDGID(uidMap, gidMap []IDMap) (int, int, error) 
{
+   if len(uidMap) == 1 && uidMap[0].Size == 1 {
+   uid = uidMap[0].HostID
+   } else {
+-  uid, err = toHost(0, uidMap)
++  uid, err = RawToHost(0, uidMap)
+   if err != nil {
+   return -1, -1, err
+   }
+@@ -90,7 +90,7 @@ func GetRootUIDGID(uidMap, gidMap []IDMap) (int, int, error) 
{
+   if len(gidMap) == 1 && gidMap[0].Size == 1 {
+   gid = gidMap[0].HostID
+   } else {
+-  gid, err = toHost(0, gidMap)
++  gid, err = RawToHost(0, gidMap)
+   if err != nil {
+   return -1, -1, err
+   }
+@@ -98,10 +98,14 @@ func GetRootUIDGID(uidMap, gidMap []IDMap) (int, int, 
error) {
+   return uid, gid, nil
+ }
+
+-// toContainer takes an id mapping, and uses it to translate a
+-// host ID to the remapped ID. If no map is provided, then the translation
+-// assumes a 1-to-1 mapping and returns the passed in id
+-func toContainer(hostID int, idMap []IDMap) (int, error) {
++// RawToContainer takes an id mapping, and uses it to translate a host ID to
++// the remapped ID. If no map is provided, then the translation assumes a
++// 1-to-1 mapping and returns the passed in id.
++//
++// If you wish to map a (uid,gid) combination you should use the corresponding
++// IDMappings methods, which ensure that you are mapping the correct ID 
against
++// the correct mapping.
++func RawToContainer(hostID int, idMap []IDMap) (int, error) {
+   if idMap == nil {
+   return hostID, nil
+   }
+@@ -114,10 +118,14 @@ func toContainer(hostID int, idMap []IDMap) (int, error) 
{
+   return -1, fmt.Errorf("Host ID %d cannot be mapped to a container ID", 
hostID)
+ }
+
+-// toHost takes an id mapping and a remapped ID, and translates the
+-// ID to the mapped host ID. If no map is provided, then the translation
+-// assumes a 1-to-1 mapping and returns the passed in id #
+-func toHost(contID int, idMap []IDMap) (int, error) {
++// RawToHost takes an id mapping and a remapped

Bug#1026598: blocked by NEW queue

[Reinhard Tartler]

In order to fix this issue, I'm waiting for
https://ftp-master.debian.org/new/rust-trust-dns-server_0.22.0-1.html to
make it out of (binary) NEW.



-- 
regards,
Reinhard

Bug#1024980: Related to Debian changes to use trust-dns 0.21

[Reinhard Tartler]

On 12/11/22 4:43 PM, Duncan Findlay wrote:

I tried reproducing this issue with several modified versions of
aardvark-dns to see if I could narrow down the cause.

I could not reproduce this with upstream source at head, nor with
upstream source at v1.0.3.


Thanks for your test report. I'm currently updating trust-dns to version 0.22,
and am hopeful that this will resolve the issue.

In fact, trust-dns in version 0.21 had to disable quite some features that
I didn't think would impact how aardvark-dns was using it. Maybe I was wrong,
in which case the upgrade would help.

-rt

Bug#1025401: unblock: libpod/4.3.1+ds1-5

[Reinhard Tartler]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package libpod

libpod needs to migrate together with:

golang-github-containers-common_0.50.1+ds1-2
golang-github-containers-buildah_1.28.0+ds1-3

[ Reason ]

There have been API changes that prevent the new libpod from building with old
versions. Also, the old libpod doesn't build with new versions of -common and
buildah. This was all successfully detected by autopkgtest.


[ Tests ]

I've manually scheduled autopkgtests on ci.debian.net to show that autopkgtests
passes with these three packages in combination.


hint libpod/4.3.1+ds1-5 golang-github-containers-common/0.50.1+ds1-2 
golang-github-containers-buildah/1.28.0+ds1-3

Bug#1024809: podman systemd service running as user deletes socket file on termination

[Reinhard Tartler]

Control: tag -1 upstream

Hi Antoine,

Thanks for testing the podman package.

On Fri, Nov 25, 2022 at 12:15 PM Antoine Musso  wrote:

> Package: podman
> Version: 3.0.1+dfsg1-3+deb11u1
> Severity: normal
>
> Dear Maintainer,
>
> I went to try running podman as a normal user using the systemd service
> and socket defined by the Debian package. Namely:
>
>   $ systemctl --user start podman.service
>
> The service requires podman.socket which creates:
>
>   /run/user/1000/podman/podman.sock
>
> podman-system-service(1) mentions the API listening services expires
> after 5 seconds and thus the service self terminate. Which is fine since
> a request made to the podman.sock would bring up the service again.
>
> However the service deletes the socket file upon completion and it is
> not recreated by podman.socket and the setup is broken.


> My workaround has been to make a copy of the service:
>
>  cp /lib/systemd/system/podman.service \
>  ~/.config/systemd/user/mypodman.service
>
> Amend it to no more relies on the podman.socket and instruct the service
> to stay up indefinitely by passing it --time 0:
>
>  ExecStart=/usr/bin/podman $LOGGING system service --time 0
>

That's an interesting find. It seems to me that you are trying to use
podman in a similar way like docker, albeit in rootless. While I'm not
really sure what's the point in using podman in this way, those systemd
user unit files are shipped upstream.

I've just checked that the most recent upstream version does not
pass --time 0 either:
https://github.com/containers/podman/blob/main/contrib/systemd/system/podman.service.in

May I ask you to please open an upstream issue at
https://github.com/containers/podman/issues/new and report back with the
issue number?

Thank you
-rt

Bug#1020540: podman-remote should be built and offered as seperate package

[Reinhard Tartler]

On Thu, Sep 22, 2022 at 7:00 PM Norbert Lange  wrote:

> Package: podman
> Version: 4.2.1-0.1
> Severity: minor
> Tags: patch
> X-Debbugs-Cc: nolang...@gmail.com
>
> Hello,
>
> I am aware of #1000521, I dont see it as resolved.
>
> The problem is that you can run podman as service, and clients
> can connect on for ex. an exposed unix socket.
>
> Practical example is:
>
> -   run rootless podman providing an unix socker
> -   run an container jenkins/inbound-agent container
> binding that socket
> -   provide a binary that takes the same arguments as docker
> while using the socket
>
> Now the issue is, that you have to install podman and its many
> dependencies in the jenkins/inbound-agent container.
>
> Way better would be to use one of the simple remote-only clients,
> this is a single file without any dependencies
> (run ldd on both).
>
> docker provides the docker-ce-cli package, podman the podman-remote
> binary.
>
> Debian should offer the package as independent package,
> so client/server can be updated together.
> Then containers can get a bind-mount to the host's
> /usr/bin/podman-remote binary.
>

Thank you for your patch. I plan on integrating it soon.

I haven't merged it yet as it would require another round through the NEW
queue, and I'd really like to get 4.3.1 into unstable first. Once we have
4.3.1 in testing, I'd like to upload your patch, as processing times
through NEW is unpredictable, and I'd like to avoid having other updates to
podman stuck for weeks or months.

-- 
regards,
Reinhard

Bug#1024032: rust-criterion: FTBFS: needs to be compiled against librust-cast (>> 0.3)

[Reinhard Tartler]

Package: librust-criterion+async-futures-dev
Severity: serious
X-Debbugs-Cc: none, Reinhard Tartler 

The rust-cast crate has been updated from version 0.2 to 0.3 on 2022/11/11.

Can you please build against that new version of rust-cast?

-rt


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

Kernel: Linux 5.19.0-2-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

Bug#1017766: podman: Failed to activate DNS. Missing dependency on golang-github-containernetworking-plugin-dnsname

[Reinhard Tartler]

Hi Michael,

On Sat, Aug 20, 2022 at 5:47 PM Michael Musenbrock <
michael.musenbr...@gmx.at> wrote:

>
>
> Now a dns-server is active in the network, but the other pods attached to
> the network
> still can't be resolved. But this may be just some config issue. I will
> check.
>
>
just checking in, did you had a chance to check whether this is a config
issue?

In any case, any chance you could describe your test setup? I'm still
looking
for a minimal test case that would be able to demonstrate the issue, and
thought
you might be able to help?

Best,
-rt


-- 
regards,
Reinhard

Bug#1019479: ITP: rust-async-std -- async version of the Rust standard library

[Reinhard Tartler]

On Sat, Sep 10, 2022 at 1:02 PM Jonas Smedegaard  wrote:

> Quoting Reinhard Tartler (2022-09-10 17:22:06)
> > Thanks Jonas for working on this.
> >
> > Btw, I've looked at packaging it independently and may have good news for
> > you:
> >
> > a) I've had some limited success with relaxing dependencies, please see
> my
> > patch attached to this email
> > b) I've packaged and uploaded two dependencies to NEW:
> > - https://ftp-master.debian.org/new/rust-sval_1.0.0~alpha.5-1.html
> > - https://ftp-master.debian.org/new/rust-value-bag_1.0.0~alpha.9-1.html
>
> Nice! Especially that those packages you've done.
>
> I don't understand how you could get rid of kv-log-macro without
> patching any Rust code - which is the part blocking me now.  But seems I
> should simply wait for your work to get approved, and then bug the Rust
> team about log crate breakage, and then try again...
>

Awesome, it seems you've also packaged kv-log-macro, so once that's in
unstable, another blocker is resolved.

Best,
rt
-- 
regards,
Reinhard

Bug#1019479: ITP: rust-async-std -- async version of the Rust standard library

[Reinhard Tartler]

Thanks Jonas for working on this.

Btw, I've looked at packaging it independently and may have good news for
you:

a) I've had some limited success with relaxing dependencies, please see my
patch attached to this email
b) I've packaged and uploaded two dependencies to NEW:
- https://ftp-master.debian.org/new/rust-sval_1.0.0~alpha.5-1.html
- https://ftp-master.debian.org/new/rust-value-bag_1.0.0~alpha.9-1.html

Hope that helps!
-rt

On Sat, Sep 10, 2022 at 5:21 AM Jonas Smedegaard  wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Jonas Smedegaard 
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> * Package name: rust-async-std
>   Version : 1.12.0
>   Upstream Author : Stjepan Glavina  and more
> * URL : https://async.rs/
> * License : Apache-2.0 or Expat
>   Programming Lang: Rust
>   Description : async version of the Rust standard library
>
>  async-std is a library
>  that looks and feels like the Rust standard library,
>  except everything in it is made to work with async/await
>  exactly as you would expect it to.
>
> This package is needed by rust-criterion.
> It will be maintained in the Debian section of Salsa, at
> https://salsa.debian.org/debian/rust-async-std
>
>  - Jonas
>
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmMcVpYACgkQLHwxRsGg
> ASFWmg/+NwUatUny1Hv+VuYmWqH0kNQaSJMZo7jrD0/5oSjcAFEFNsDQhnpairAR
> We52Qqds0m9a90A/w9FSjJnHrBfexmOJ9w0Nho4V9KcEat7Ia18GqS0G/REvr4QF
> xJj2pV2WRHz0cuegc711tT1W8qbOPKvz7D6MhzlrrGHB7z3Jj2mCp2Am9UBW7Nov
> TD/6cw31aDbZpnxmBJUys/UmEdkycg4fa0SBg5jQGtvWO2Vj1ifPnPlF+YV2Djh9
> 2JnBkydYDeE0eU9C81b9h0BFvC0fR9VWe6XKFLwHC3NePhC+CIka9NU6ANjvOAzb
> PPHFMNiS7dgr5+Ke7Jd4j1g3BEOloS1m1Mr2MYFY46g3SybSMk/dNcxMVe7L1TQN
> XMAzr6hjC/dqpjapiXvK4eW66rfgBKN9M0PEnGWXVF3skbvmWKRyIP/6tu8DtAVz
> DDOOjuR/256gM5fEEqHWNRxaufg+m0rQEKFgvegv8K4aiTu5qL9JfzQxBph/6AsM
> qEnmg0vhNK9RP77eNE06uXmlbXIDJx06Bu2MdrkzhjK4lelJ50OtwCuSdSlt99Px
> 1X42PlmOP4JLRSQa/JjzBUpz4nUaUNK0Or7EPVFt8oOpRw3wLq4PsVhQbiPqX5Um
> YI0UHlmTO9nb91Fs74suS5J/USgatRvEGY8Tukd9oLEPx11CIt0=
> =XQhF
> -END PGP SIGNATURE-
>
>

-- 
regards,
Reinhard
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -80,10 +80,6 @@
 version = "0.3.4"
 optional = true
 
-[dependencies.kv-log-macro]
-version = "1.0.6"
-optional = true
-
 [dependencies.log]
 version = "0.4.8"
 features = ["kv_unstable"]
@@ -139,10 +135,8 @@
 "async-global-executor",
 "async-io",
 "futures-lite",
-"kv-log-macro",
 "log",
 "pin-project-lite",
-"gloo-timers",
 ]
 docs = [
 "attributes",
@@ -158,7 +152,6 @@
 "once_cell",
 "pin-utils",
 "slab",
-"wasm-bindgen-futures",
 "futures-channel",
 "async-channel",
 "async-lock",
@@ -193,15 +186,6 @@
 version = "0.3.4"
 optional = true
 
-[target."cfg(target_arch = \"wasm32\")".dependencies.gloo-timers]
-version = "0.2.1"
-features = ["futures"]
-optional = true
-
-[target."cfg(target_arch = \"wasm32\")".dependencies.wasm-bindgen-futures]
-version = "0.4.10"
-optional = true
-
 [target."cfg(target_arch = \"wasm32\")".dev-dependencies.getrandom]
 version = "0.2.0"
 features = ["js"]

Bug#1019206: librust-criterion+async-std-dev: Package is uninstallable, rust-async-std missing in debian

[Reinhard Tartler]

Package: librust-criterion+async-std-dev
Severity: serious
Justification: packages must be installable, prevents other packages from 
reaching testing
X-Debbugs-Cc: d...@jones.dk, debian-r...@lists.debian.org

The package librust-criterion+async-std-dev is currently uninstallable in
unstable and testing, which prevents it and other dependent packages (like
rust-rustls) from reaching testing. Currently, this even threats the removal
unrelated packages from testing, cf. #1018225

I see two options out here:

 a) disable the 'async-std' feature
 b) package 'async-std'

Note that while working on the rust-rtnetlink package, a similar issue popped 
up, and I've
opted for option a). Should 'async-std' become available, I'd be happy to 
change 'rust-rtnetlink'
to enable the 'async-std' feature.

Best,
-rt


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

Kernel: Linux 5.18.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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages librust-criterion+async-std-dev depends on:
pn  librust-async-std-1+default-dev  
pn  librust-criterion-dev

librust-criterion+async-std-dev recommends no packages.

librust-criterion+async-std-dev suggests no packages.

Bug#1017766: podman: Failed to activate DNS. Missing dependency on golang-github-containernetworking-plugin-dnsname

[Reinhard Tartler]

>From the list of packages in your big report i see that the packages
netavark and aardvark-dns are absent. Does installing them work for your
without the golang-github-containernetworking-plugin-dnsname package?


One of the main major changes in podman 4 is the rust based networking
stack. It should be installed by default for new installations. Did this
not happen or is this an upgrade situation?

-rt

On Fri, Aug 19, 2022, 23:39 Michael Musenbrock 
wrote:

> Package: podman
> Version: 4.2.0+ds1-3
> Severity: important
>
> Hi,
>
> thanks for bringing up-to-date podman packages to Debian. This is really
> nice to have those current version available.
>
> With the latest version of the podman packages (4.2.0+ds1-3) dns
> resolution fails for podman networks.
>
> This could simply be resolved by installing
> 'golang-github-containernetworking-plugin-dnsname'. I think this should be
> installed automatically via dependencies.
>
> hth, keep up the nice work
> regards Michael
>
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (504, 'unstable'), (503, 'testing'), (502, 'experimental'),
> (1, 'experimental-debug')
> merged-usr: no
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.18.0-4-amd64 (SMP w/16 CPU threads; PREEMPT)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US:en
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages podman depends on:
> ii  conmon   2.1.3+ds1-1
> ii  crun 1.5+dfsg-1+b1
> ii  golang-github-containers-common  0.49.1+ds1-1
> ii  libc62.34-4
> ii  libdevmapper1.02.1   2:1.02.185-1
> ii  libgpgme11   1.17.1-4
> ii  libseccomp2  2.5.4-1+b1
> ii  runc 1.1.3+ds1-7
> ii  systemd [systemd-tmpfiles]   251.4-1
>
> Versions of packages podman recommends:
> ii  buildah1.27.0+ds1-5
> ii  catatonit  0.1.7-1
> ii  dbus-user-session  1.14.0-2
> ii  fuse-overlayfs 1.9-1
> ii  slirp4netns1.2.0-1
> ii  tini   0.19.0-1
> ii  uidmap 1:4.11.1+dfsg1-2
>
> Versions of packages podman suggests:
> ii  containers-storage  1.42.0+ds1-1
> ii  docker-compose  1.29.2-1
> ii  iptables1.8.8-1
>
> -- no debconf information
>
>

Bug#1009776: podman: Packages uidmap and slirp4netns should be full dependencies

[Reinhard Tartler]

Control: tag -1 wontfix

On Fri, May 6, 2022 at 7:03 PM Andrej Shadura <
andrew.shad...@collabora.co.uk> wrote:

>
>
> Indeed. When I ran into this in #983395, I was told here I’m supposed to
> use sudo (or install Recommends, which IIRC are disabled in Docker
> images), while the upstream told me I should use rootless mode.
> Eventually I managed to get a change merged to improve the error
> message, but I still find this a bit suboptimal. Just installing the
> package should make the most desired mode work without fiddling with it,
> and the upstream states that mode is rootless mode, hence uidmap and its
> friend should be in Depends, not Recommends.
>

I have to respectfully disagree here. In Debian, "Recommends" relationships
are installed by default, and your message indicates to me that you have
configured your system to not install them. It furthermore seems to me that
this bug is asking for a convenience that is making your non-standard setup
easier, while making other setups where podman is used only in 'root' mode,
impossible to install without idmap and friends.
I'm going to leave this bug open to remind myself to think about this from
time to time, but I still wanted to document my thinking process here more
clearly.

Thanks for your input nevertheless!

-- 
regards,
Reinhard

Bug#1009747:

[Reinhard Tartler]

Hi Anatoli,

Sorry to hear that you had bad surprises with the podman package, but I'm
happy to read in
https://github.com/containers/podman/issues/12983#issuecomment-1119662438
that you managed to get the software working by rebooting. This tells me
that those warnings correctly indicated a system misconfiguration or rather
an runtime error and your dbus user session wasn't running.

I'm going to change the podman package to add a "Recommends" relationship
so that the package gets installed by default.

Thanks for your bugreport.

On Sat, Apr 16, 2022 at 12:03 PM Anatoli Babenia 
wrote:

> It appears installing `dbus-user-session` doesn't fix the problem with
> excessive messages.
>
>

-- 
regards,
Reinhard

Bug#1016961: reverse dependency

[Reinhard Tartler]

> Hi Reinhard,

> there is a reverse dependency that needs to be taken care of:


> Checking reverse dependencies...
> # Broken Build-Depends:
> aardvark-dns: librust-trust-dns-proto-dev


> This needs to be addressed first. Please remove the moreinfo tag once that 
> is done.

Hi Thorsten,

I don't follow, and I don't think anything needs to be addressed here.

aardvark-dns is NOT built on any architectures that I requested this partial 
removal of. In fact, I expect this request to allow aardvark-dns to migrate to 
testing, because all of its dependencies can migrate.

I may certainly have misunderstood. In that case, can you please help me with 
more some more specific directions in how to resolve this issue?

Thank you so much for your patience with me.

Best,
-rt