Bug#955016: vpnc-scripts: Fix incompatibility with iproute2 >= 5.1 syncing with upstream
Package: vpnc-scripts Version: 0.1~git20190117-1 Severity: minor vpnc-scripts has become incompatible with iproute2 >= 5.1 (applies to bullseye and sid as of now) and is therefore reporting issues with calls to "ip route get", but it's still working. This issue has been reported upstream [1] and a fix has been already merged [2]. Simply updating the package to the upstream repository would eliminate the ugly error messages. [1] https://gitlab.com/openconnect/openconnect/-/issues/106 [2] https://gitlab.com/openconnect/vpnc-scripts/-/merge_requests/5 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) 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.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages vpnc-scripts depends on: ii iproute2 5.5.0-1 ii net-tools 1.60+git20180626.aebd88e-1 vpnc-scripts recommends no packages. Versions of packages vpnc-scripts suggests: pn dnsmasq ii openssh-server 1:8.2p1-4 pn resolvconf -- no debconf information
Bug#953533: Additional information
Sorry, I attached a wrong patch to my previous e-mail. Attached to this message I send a patch that works for me. On Wed, 2020-03-11 at 11:26 +0100, Silvano Cirujano Cuesta wrote: > Additional input: > > Commit 10c5f39b [1] appears to be the origin of the issue. It expects the > bash completions to be > under debian/tmp/etc, but they get installed to debian/tmp/usr/share. > > [1] > https://salsa.debian.org/opensc-team/opensc/-/commit/10c5f39ba255a540cafe7164bfc0382dee0ad24a From 5f877dc1c4f7e3664208a8b052d86be916ee5c10 Mon Sep 17 00:00:00 2001 From: Silvano Cirujano Cuesta Date: Wed, 11 Mar 2020 11:19:08 +0100 Subject: [PATCH] Fix path to bash completion configs Signed-off-by: Silvano Cirujano Cuesta --- debian/opensc.install | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/opensc.install b/debian/opensc.install index 6213ab66..777199fc 100644 --- a/debian/opensc.install +++ b/debian/opensc.install @@ -1,5 +1,5 @@ debian/tmp/usr/bin/* -debian/tmp/etc/bash_completion.d/* usr/share/bash-completion/completions +debian/tmp/usr/share/bash-completion/completions/* usr/share/bash-completion/completions debian/tmp/usr/share/man/man1/* debian/tmp/usr/share/man/man5/* -- 2.25.1
Bug#953533: Additional information
Additional input: Commit 10c5f39b [1] appears to be the origin of the issue. It expects the bash completions to be under debian/tmp/etc, but they get installed to debian/tmp/usr/share. [1] https://salsa.debian.org/opensc-team/opensc/-/commit/10c5f39ba255a540cafe7164bfc0382dee0ad24a From 5f877dc1c4f7e3664208a8b052d86be916ee5c10 Mon Sep 17 00:00:00 2001 From: Silvano Cirujano Cuesta Date: Wed, 11 Mar 2020 11:19:08 +0100 Subject: [PATCH] Fix path to bash completion configs Signed-off-by: Silvano Cirujano Cuesta --- debian/opensc.install | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/opensc.install b/debian/opensc.install index 6213ab66..777199fc 100644 --- a/debian/opensc.install +++ b/debian/opensc.install @@ -1,5 +1,5 @@ debian/tmp/usr/bin/* -debian/tmp/etc/bash_completion.d/* usr/share/bash-completion/completions +debian/tmp/usr/share/bash_completion.d/* usr/share/bash-completion/completions debian/tmp/usr/share/man/man1/* debian/tmp/usr/share/man/man5/* -- 2.25.1
Bug#953533: opensc: Fails to build due to missing bash_completion files
Package: opensc Version: 0.20.0-3 Severity: serious Justification: fails to build from source (but built successfully in the past) Tags: ftbfs Trying to build fails. I've tried following two ways. I've tried apt-get source opensc ; debuild -b -uc -us and apt-get --build source opensc The error message is: dh_install: warning: Cannot find (any matches for) "debian/tmp/etc/bash_completion.d/*" (tried in ., debian/tmp) dh_install: warning: opensc missing files: debian/tmp/etc/bash_completion.d/* dh_install: error: missing files,aborting make: *** [debian/rules:4: binary] Error 25 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) 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.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages opensc depends on: ii libc6 2.29-10 ii libreadline8 8.0-4 ii libssl1.1 1.1.1d-2 ii opensc-pkcs11 0.20.0-3 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages opensc recommends: ii pcscd 1.8.26-3 opensc suggests no packages. -- Configuration Files: /etc/opensc/opensc.conf changed [not included] -- no debconf information
Bug#930440: Installation of "policy.json" expected to be done by recommended package
In the past "policy.json" was being installed by this package, but this behavior got changed: https://salsa.debian.org/debian/libpod/commit/3980d63cbc13c51369f3540eb32e53391199b91d Now it's expected to get the policy installed by another recommended package: "buildah". I suppose that such a change was needed to avoid two Debian packages that are compatible trying to manage the same file. Am I right? But probably some prominent way to tell the user about how to get "policy.json" (and probably also "registries.conf") is needed. If not, people will be frequently stumbling over it. I did and someone else also did: https://github.com/containers/libpod/issues/1742#issuecomment-570952262 I first thought on some message on installation, what might be useful. But in the end probably the place where it's failing is the best place to let the user know about the solution... What about minor patching to report the potential issues? Patching CheckForRegistries@cmd/podman/platform_linux.go [1] would suffice for "registries.conf". I haven't found yet the place where the issue with "policy.json" gets reported... [1] https://github.com/containers/libpod/blob/master/cmd/podman/platform_linux.go#L16
Bug#930440: Success report
The result of building the current latest commit [1] and installing on a system with a 'Testing/Bullseye' looks good. I'm not running any automatic tests on it or so, but following worked: - Pulling a remote image both as root and rootless. - Starting a container both root and rootless. - Establishing outgoing connections from a container both root and rootless. I've also tested that at least 'podman info' doesn't fail on absent of fuse-overlayfs and slirp4netns. [1] https://salsa.debian.org/debian/libpod/tree/93569f78585a4affd7e957eb0a27c5bb9dbef580
Bug#930440: Missing file: /etc/containers/policy.json
No default is being provided for the signature verification policy: /etc/containers/policy.json According the Readme (/usr/share/doc/podman/README.Debian) the default should be there to be reviewed. Best, Silvano
Bug#930720: Dependency "linux-headers-xyz" missing, needed for BPF compilation
Hi Ritesh, Thanks for quick answers and the link to the enlightening bug report! I'm nevertheless the opinion, that some kind of more helpful reporting should be used. Perhaps upstream? BR, Silvano On Wed, 2019-06-19 at 17:39 +0530, Ritesh Raj Sarraf wrote: > On Wed, 2019-06-19 at 09:21 +, Cirujano Cuesta, Silvano wrote: > > IMHO it should be a "Depends" dependency, or at least a "Recommends" > > dependency. > > We can't do that. The same is explained in the following bug report: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877925 > > That is the reason I documented it into the README.Debian file. This is > similar to the case of the systemtap package. Both of which serve > similar purposes. > > Thanks, > Ritesh >
Bug#930720: Dependency "linux-headers-xyz" missing, needed for BPF compilation
Package: bpfcc-tools
Version: 0.8.0-4
Executing execsnoop-bpfcc (and probably any of the other BCC tools) fails due
to a missing directory (/lib/modules/4.19.0-5-amd64/build) on an up-to-date
Buster system.
Installing 'linux-headers-amd64' (on an AMD64 system) resolved the issue.
This is an example of the reported error.
# execsnoop-bpfcc
chdir(/lib/modules/4.19.0-5-amd64/build): No such file or directory
Traceback (most recent call last):
File "/usr/sbin/execsnoop-bpfcc", line 166, in
b = BPF(text=bpf_text)
File "/usr/lib/python2.7/dist-packages/bcc/__init__.py", line 320, in __init__
raise Exception("Failed to compile BPF text")
Exception: Failed to compile BPF text
Bug#923722: golang-github-appc-cni: Please upgrade to new upstream 0.7.0-alpha1
Hi Reinhard, On Mon, 2019-03-04 at 07:20 -0500, Reinhard Tartler wrote: > Package: golang-github-appc-cni > Severity: wishlist > > Hi, > > Please update to new upstream version of 0.7.0-alpha1. I need it as a > build dependency of http://github.com/containers/buildah By now you could try to get 0.7.1, released a couple of hours ago: https://github.com/containernetworking/cni/releases/tag/v0.7.1 > > In fact, I've done so locally, and would be happy to upload it as a Team > Upload. I was running into issues while doing so. Unlike the git > repositories created by the dh-make-golang tool, the git repository on > salsa at > https://salsa.debian.org/go-team/packages/golang-github-appc-cni does > not include full sources in the packaging branch. I am unfamiliar with > that workflow and it is inconsistent with how the vast majority of the > packages in the golang team are handled. I therefore decided to start > off from a 'dgit clone' created repository. > > Dimtry, I wonder what your thoughts on this issue are. Would you be OK > with switching the workflow? If not, could you please upload > 0.7.0-alpha1 to experimental soon? Alternatively, I could upload the > package that I have locally to experimental, and leave updating salsa to > you (or someone else) whenever time permits. > > What does the rest of the team think about competing git repository > workflows within the team? At least to me, this seems undesireable > because it prompts convesations like this (which I really don't enjoy > having). I'm also puzzled why this packaging. Just my 2 cents, although I'm not part of the team, but having a look at some packages needed for containers. > > Best, > -rt > A different, but related question. Are there any known efforts to package the reference plugins? BR, Silvano
Bug#922842: ITP: golang-github-containers-image -- Work with containers' images
On Tue, 2019-04-30 at 07:20 -0400, Reinhard Tartler wrote: > > I'm not familiar with building packages that way, please excuse my ignorance, > but I'd rather focus on tools that I can actually use for uploading packages > to Debian. I'm afraid that I'm probably > unable to help you with this baseimage and/or approach to build packages. I can understand that, but my problem is that I don't know 'sbuild' and while trying to set it up I'm facing too many unknown tools and proxy issues :-/ > > > I prefer not to use too much magic (although using containers involves > > per-se some magic) to better understand what's going on. > > Same here. I took a look at > https://github.com/debuerreotype/docker-debian-artifacts/blob/064f343bfa6ebf043aac2bbd4c870256cfe82f5a/sid/slim/Dockerfile > and it does look pretty magical to me ;-) How that root-filesystem is built is much magic, I agree with you. But you end up with a Debian root-filesystem as small as ~60MB and very very few packages installed. And once I have the container and I'm building in it, there's no much more magic involved anymore. > > There is not much magic with sbuild, please see > https://wiki.debian.org/sbuild to get started. As mentioned above, setting up 'schroot', configuring the proxy, ... it's not that easy if you have never done it. > > > I don't think that it's a language barrier. > > But possibly an expertise barrier: my expertise on building Debian packages > > (specially for Go) is not as extensive as yours :-) > > I don't claim extensive experience with Go, or Go packaging, but I think I do > have a reasonable grasp of Debian packaging tools. It's good to have someone with your expertise working on it! > > What I find puzzling in your buildlog is that while you do use > dpkg-buildpackage, it fails to apply the quilt patches. 'dpkg-buildpackage' doesn't patch for you, you have to do it on advance yourself. > > Good luck! > -rt Even with a separate workflow, I'm still the opinion that the patch of 'ostree/ostree_src.go' [1] results in invalid Go code. Can you somehow see the intermediate files being created? Aren't you getting an empty 'ostree/ostree_src.go' file? That should make the Go compilation fail. I wonder if some 'sbuild' magic is getting rid of the empty Go file before the compilation starts and therefore you don't face the issue... Unfortunately I don't have that much time work on confirming the issue. So if you can build it and provide the result via the repository mentioned in [2], then I suppose it's fine for me :-D [2] https://github.com/containers/libpod/issues/1742#issuecomment-487910563 Cheers, Silvano
Bug#923300: ITP: golang-github-openshift-imagebuilder -- Builds Dockerfile using the Docker client
> I actually went ahead and implement this solution. The result can be seen at > https://salsa.debian.org/go-team/packages/golang-github-openshift-imagebuilder The project doesn't appear to be there, isn't it public? I'm trying to build 'buildah' and I'm missing this dependency. Silvano
Bug#922842: ITP: golang-github-containers-image -- Work with containers' images
Basically what happens is that the patch 'ostree-stub.patch' produces an empty file 'ostree_src.go' and the compiler doesn't accept an empty Go file. My affirmation WRT the path can be confirmed by reading the patch itself [2] or just applying it. [2] https://salsa.debian.org/go-team/packages/golang-github-containers-image/blob/master/debian/patches/ostree-stub.patch#L1104 The error reported by the compiler is (see full buildlog below): can't load package: package github.com/containers/image/ostree: obj-x86_64-linux-gnu/src/github.com/containers/image/ostree/ostree_src.go:1:1: expected 'package', found 'EOF' On Mon, 2019-04-29 at 07:29 -0400, Reinhard Tartler wrote: > I'm having a hard time understanding what issue you are facing with and what > you mean fix "fix manually". How are you building the package? Are you using > git-buildpackage, sbuild or pbuilder? I'd > strongly recommend to do so, because if you were, I cannot see how you > possibly could run into such issues. I'm using none of them, I'm building "the hard way": in a container (from Docker base image debian:sid-slim) with a script that runs the individual steps and builds with 'dpkg-buildpackage'. It should be possible to build these packages this way, right? It usually works. I prefer not to use too much magic (although using containers involves per-se some magic) to better understand what's going on. What I meant with "fix manually" is executing "rm ostree/ostree_src.go" right after patching and before building. I don't know if the 'magic' of any of the mentioned tools is just silently fixing the issue for you and that's why you are not facing it... > In any case, a full buildlog, similar to what I attached, could be helpful. > If English is a language barrier, try explaining in German. I don't think that it's a language barrier. But possibly an expertise barrier: my expertise on building Debian packages (specially for Go) is not as extensive as yours :-) --- dpkg-buildpackage: info: source package golang-github-containers-image dpkg-buildpackage: info: source version 1.5-1 dpkg-buildpackage: info: source distribution UNRELEASED dpkg-buildpackage: info: source changed by Reinhard Tartler dpkg-buildpackage: info: host architecture amd64 dpkg-source --before-build . debian/rules clean dh clean --buildsystem=golang --with=golang dh_auto_clean -O--buildsystem=golang dh_autoreconf_clean -O--buildsystem=golang dh_clean -O--buildsystem=golang debian/rules build dh build --buildsystem=golang --with=golang dh_update_autotools_config -O--buildsystem=golang dh_autoreconf -O--buildsystem=golang dh_auto_configure -O--buildsystem=golang debian/rules override_dh_auto_build make[1]: Entering directory '/debian-packages/golang-github-containers-image' dh_auto_build -O--buildsystem=golang -- -tags "containers_image_ostree_stub" can't load package: package github.com/containers/image/ostree: obj-x86_64-linux-gnu/src/github.com/containers/image/ostree/ostree_src.go:1:1: expected 'package', found 'EOF' cd obj-x86_64-linux-gnu && go install -gcflags=all=\"-trimpath=/debian-packages/golang-github-containers-image/obj-x86_64-linux-gnu/src\" -asmflags=all=\"-trimpath=/debian-packages/golang-github-containers-image/obj-x86_64-linux-gnu/src\" -v -p 4 -tags containers_image_ostree_stub github.com/containers/image github.com/containers/image/copy github.com/containers/image/directory github.com/containers/image/directory/explicitfilepath github.com/containers/image/docker github.com/containers/image/docker/archive github.com/containers/image/docker/daemon github.com/containers/image/docker/policyconfiguration github.com/containers/image/docker/reference github.com/containers/image/docker/tarfile github.com/containers/image/image github.com/containers/image/internal/testing/explicitfilepath-tmpdir github.com/containers/image/internal/testing/mocks github.com/containers/image/internal/tmpdir github.com/containers/image/manifest github.com/containers/image/oci github.com/containers/image/oci/archive github.com/containers/image/oci/internal github.com/containers/image/oci/layout github.com/containers/image/pkg/blobinfocache github.com/containers/image/pkg/compression github.com/containers/image/pkg/docker/config github.com/containers/image/pkg/strslice github.com/containers/image/pkg/sysregistries github.com/containers/image/pkg/sysregistriesv2 github.com/containers/image/pkg/tlsclientconfig github.com/containers/image/signature github.com/containers/image/storage github.com/containers/image/tarball github.com/containers/image/transports github.com/containers/image/transports/alltransports github.com/containers/image/types github.com/containers/image/version github.com/containers/image errors internal/race internal/cpu runtime/internal/sys runtime/internal/atomic sync/atomic unicode unicode/utf8 internal/testlog internal/bytealg math math/bits encoding unicode/utf16
Bug#922842: ITP: golang-github-containers-image -- Work with containers' images
Commit c17b0346 is changing the patching of the 'ostree' directory in a way that generates an invalid Go package. Instead of removing 'ostree/ostree_src.go', it's replacing it with an empty file that breaks 'go build'. If I manually fix it, it builds successfully. Cheers, Silvano [1] https://salsa.debian.org/go-team/packages/golang-github-containers-image/commit/c17b0346163f88028e5675600865ac2eb95e051d
Bug#922842: ITP: golang-github-containers-image -- Work with containers' images
On Fri, 2019-04-26 at 21:50 -0400, Reinhard Tartler wrote: > Are you sure that you applied the patches from 'debian/patches'? Ups, no. That's probably the issue. I'll let you know if it works or not, once I've tested it. Silvano
Bug#880199: Packaging blockers
Hi, > 2019/01/09 06:54:27 Build-Dependency "github.com/opencontainers/image-tools" > is not yet available in Debian, or has not yet been converted to use > XS-Go-Import-Path in debian/control > The latter one is #900900, the first two don't seem to be worked on yet. The build dependency "github.com/opencontainers/image-tools" is being declared as "golang-github-opencontainers-image-tools-image-dev" [1], right? But the mentioned ITP Bug #900900 [2] is not providing any package under that name [3]... And I cannot find any package, ITP or RFP providing "golang-github-opencontainers-image-tools-image-dev". I'm really puzzled... Am I missing something? Silvano [1] https://salsa.debian.org/go-team/packages/skopeo/blob/master/debian/control#L13 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900900 [3] https://salsa.debian.org/go-team/packages/oci-image-tools/blob/master/debian/control
Bug#922842: ITP: golang-github-containers-image -- Work with containers' images
Build is failing. If I'm right, fetching the vendor components is missing. But I don't know how to get it in... BTW, please make sure that your packaging is not affected by issue 620 [1] of containers/image. The environment where I'm testing is, on purpose, a pristine Debian installation where GOBIN is not part of PATH. [1] https://github.com/containers/image/issues/620 Silvano This is the error message: dh_auto_build -O--buildsystem=golang -- -tags "containers_image_ostree_stub" cd obj-x86_64-linux-gnu && go install -gcflags=all=\"-trimpath=/debian-packages/golang-github-containers-image/obj-x86_64-linux-gnu/src\" -asmflags=all=\"-trimpath=/debian-packages/golang- github-containers-image/obj-x86_64-linux-gnu/src\" -v -p 4 -tags containers_image_ostree_stub github.com/containers/image github.com/containers/image/copy github.com/containers/image/directory github.com/containers/image/directory/explicitfilepath github.com/containers/image/docker github.com/containers/image/docker/archive github.com/containers/image/docker/daemon github.com/containers/image/docker/policyconfiguration github.com/containers/image/docker/reference github.com/containers/image/docker/tarfile github.com/containers/image/image github.com/containers/image/internal/testing/explicitfilepath-tmpdir github.com/containers/image/internal/testing/mocks github.com/containers/image/internal/tmpdir github.com/containers/image/manifest github.com/containers/image/oci github.com/containers/image/oci/archive github.com/containers/image/oci/internal github.com/containers/image/oci/layout github.com/containers/image/openshift github.com/containers/image/ostree github.com/containers/image/pkg/blobinfocache github.com/containers/image/pkg/compression github.com/containers/image/pkg/docker/config github.com/containers/image/pkg/strslice github.com/containers/image/pkg/sysregistries github.com/containers/image/pkg/sysregistriesv2 github.com/containers/image/pkg/tlsclientconfig github.com/containers/image/signature github.com/containers/image/storage github.com/containers/image/tarball github.com/containers/image/transports github.com/containers/image/transports/alltransports github.com/containers/image/types github.com/containers/image/version src/github.com/containers/image/signature/mechanism_gpgme.go:11:2: cannot find package "github.com/mtrmac/gpgme" in any of: /usr/lib/go-1.11/src/github.com/mtrmac/gpgme (from $GOROOT) /debian-packages/golang-github-containers-image/obj-x86_64-linux-gnu/src/github.com/mtrmac/gpgme (from $GOPATH) src/github.com/containers/image/openshift/openshift-copies.go:23:2: cannot find package "k8s.io/client-go/util/homedir" in any of: /usr/lib/go-1.11/src/k8s.io/client-go/util/homedir (from $GOROOT) /debian-packages/golang-github-containers-image/obj-x86_64-linux-gnu/src/k8s.io/client-go/util/homedir (from $GOPATH) dh_auto_build: cd obj-x86_64-linux-gnu && go install -gcflags=all=\"-trimpath=/debian-packages/golang-github-containers-image/obj-x86_64-linux-gnu/src\" -asmflags=all=\"-trimpath=/debian- packages/golang-github-containers-image/obj-x86_64-linux-gnu/src\" -v -p 4 -tags containers_image_ostree_stub github.com/containers/image github.com/containers/image/copy github.com/containers/image/directory github.com/containers/image/directory/explicitfilepath github.com/containers/image/docker github.com/containers/image/docker/archive github.com/containers/image/docker/daemon github.com/containers/image/docker/policyconfiguration github.com/containers/image/docker/reference github.com/containers/image/docker/tarfile github.com/containers/image/image github.com/containers/image/internal/testing/explicitfilepath-tmpdir github.com/containers/image/internal/testing/mocks github.com/containers/image/internal/tmpdir github.com/containers/image/manifest github.com/containers/image/oci github.com/containers/image/oci/archive github.com/containers/image/oci/internal github.com/containers/image/oci/layout github.com/containers/image/openshift github.com/containers/image/ostree github.com/containers/image/pkg/blobinfocache github.com/containers/image/pkg/compression github.com/containers/image/pkg/docker/config github.com/containers/image/pkg/strslice github.com/containers/image/pkg/sysregistries github.com/containers/image/pkg/sysregistriesv2 github.com/containers/image/pkg/tlsclientconfig github.com/containers/image/signature github.com/containers/image/storage github.com/containers/image/tarball github.com/containers/image/transports github.com/containers/image/transports/alltransports github.com/containers/image/types github.com/containers/image/version returned exit code 1 make[1]: *** [debian/rules:11: override_dh_auto_build] Error 1 On Thu, 2019-02-21 at 06:49 -0500, Reinhard Tartler wrote: > Package: wnpp > Severity: wishlist > Owner: Reinhard Tartler > > * Package name: golang-github-containers-image > Version : 1
