om
>
> if [ -e $mandir/man1/$i.$srcext ]; then
>
> to
>
> if [ -e $mandir/man1/$i.$srcext && -e /usr/share/man/man1 ]; then
>
>
What's the status of this bug? We are also stumbling over it.
Thanks!
Silvano Cirujano Cuesta
On 25/03/2021 19:24, Michael Tokarev wrote:
> 25.03.2021 16:33, Silvano Cirujano Cuesta wrote:
>> Package: qemu-user-static
>> Version: 1:5.2+dfsg-9
>> Severity: wishlist
>> X-Debbugs-Cc: silvano.cirujano-cue...@siemens.com
>>
>> Current packaging of qemu
Package: qemu-user-static
Version: 1:5.2+dfsg-9
Severity: wishlist
X-Debbugs-Cc: silvano.cirujano-cue...@siemens.com
Current packaging of qemu-user-static is providing two different things
at once and without any declared configuration possibility (no .conffiles):
* QEMU-User statically linked bi
Great, thanks!
Silvano
On 10/03/2021 19:07, Reinhard Tartler wrote:
> Control: reassign -1 libpod
> Control: merge -1 984772
> Hi Silvano,
>
> I'm taking care of this with this email by merging the two bugs.
>
> Best,
>
> On 3/8/21 9:17 AM, Silvano Ciruj
Source: libpod
Version: 3.0.0 and higher
Severity: wishlist
X-Debbugs-Cc: silvano.cirujano-cue...@siemens.com
Similarly to archlinux and the RedHad distributions family, Debian
should provide a package that enables replacing Docker CLI and API
emulating both with Podman.
The upstream project libp
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: silvano.cirujano-cue...@siemens.com
* Package name: podman-docker
Version : 3.0.0
Upstream Author : The Podman Community
* URL : https://github.com/containers/podman
* License : Apache License 2.0
Programming Lang
Package: opensc
Version: 0.20.0-4
Severity: important
Tags: upstream patch
X-Debbugs-Cc: silvano.cirujano-cue...@siemens.com
Upgrading the package to the newest OpenSC release "0.21.0" would fix
bug 961123: "opensc: support for CardOS 5.3 broken in 0.20.0". I'm
assigning this bug the same severity
Package: opensc
Version: 0.20.0-4
Severity: important
Tags: upstream patch
OpenSC version 0.20.0 broke the support for CardOS 5.3 smartcards. It
potentially also breaks CardOS 5.0 and other 5.x smartcards (if any
exist).
People with a CardOS 5.3 smartcard can reproduce the issue with the
command
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] an
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 th
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
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 ope
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 chan
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.
- Establi
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
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
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 exa
t; Best,
> -rt
>
A different, but related question. Are there any known efforts to package the
reference plugins?
BR,
Silvano
tting 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
> 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
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/
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 s
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
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:/
tallation 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=\"-t
quent releases in 2014 and is currently on 3.64 (released
> on 25 May).
>
Version 3.73 is now available.
--
Silvano Sallese silvano AT pluto.it
Italian Linux Documentation Projecthttp://pluto.it/ildp
PLUTO Web
26 matches
Mail list logo
