Bug#975651: Request: upgrade to new upstream version 0.21.0
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 and tags as 961123. References: Upstream release 0.21.0: https://github.com/OpenSC/OpenSC/releases/tag/0.21.0 Debian bug 961123: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961123 Upstream issue 1987: https://github.com/OpenSC/OpenSC/pull/1987 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (50, 'unstable'), (10, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-2-amd64 (SMP w/4 CPU threads) 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 not set 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.31-4 ii libreadline8 8.1~rc2-2 ii libssl1.1 1.1.1h-1 ii opensc-pkcs11 0.20.0-4 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages opensc recommends: ii pcscd 1.9.0-1 opensc suggests no packages. -- Configuration Files: /etc/opensc/opensc.conf changed [not included] -- no debconf information
Bug#984770: RFP: podman-docker -- Emulate Docker CLI and API using Podman.
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: Mostly configurations Description : Emulate Docker CLI and API using Podman. Podman from 3.0.0 and upwards supports the Docker API and can be used to emulate Docker. This package provides the needed means to do a seamless replacement of Docker for both CLI and API. It also makes Docker manpages be redirected to Podman manpages. Before Podman 3.0.0 the usage of a Podman alias as Docker was the recommended approach. Since Podman 3.0.0 supports the Docker API, the more sophisticated approach of this package is needed to take full advantage of Podman. This package enables using docker-compose with Podman without Docker at all. This package replicates the functionality being provided by the archlinux package under the same bame [1]. RedHat distribution family (CentOS, RHEL, Fedora,...) also provide the same package although I couldn't find a link. [1] https://archlinux.org/packages/community/x86_64/podman-docker/
Bug#984772: libpod: add binary package "podman-docker" for Docker API emulation
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 libpod (being packaged by the Debian source package "libpod") provides all needed files. As the archlinux packaging shows [1], only a build with the special Makefile target "install.docker" is needed. This binary package would require "podman">3.0.0 and would conflict with docker.io (is it even possible to make it conflict with the package provided by Docker Inc.?). [1] https://github.com/archlinux/svntogit-community/blob/f3bea61b48de022cb805830979675131ab54001f/trunk/PKGBUILD#L51 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (50, 'unstable'), (10, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads) 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=sh: 0: getcwd() failed: No such file or directory UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#984770: Bug#984772: libpod: add binary package "podman-docker" for Docker API emulation
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 Cirujano Cuesta wrote: >> Dear libpod maintainers, >> >> unfortunately I've realized that building the binary package out of the >> already existing source package "libpod" is the right approach after posting >> this request: >> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.debian.org%2Fcgi-bin%2Fbugreport.cgi%3Fbug%3D984770&data=04%7C01%7Csilvano.cirujano-cuesta%40siemens.com%7Cc737e3a1217c4389673c08d8e3ef5526%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637509964371809863%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=jTTf9X2cBVngG7vyF4Xpn8F0l8dhm0NwlLESW1JnmXw%3D&reserved=0. >> But I cannot close it. Can you do it? >> >> Thanks! >> >> Silvano >> >> On 08/03/2021 10:22, [ext] Silvano Cirujano Cuesta wrote: >>> 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 libpod (being packaged by the Debian source package >>> "libpod") provides all needed files. As the archlinux packaging shows [1], >>> only a build with the special Makefile target "install.docker" is needed. >>> >>> This binary package would require "podman">3.0.0 and would conflict with >>> docker.io (is it even possible to make it conflict with the package >>> provided by Docker Inc.?). >>> >>> [1] >>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Farchlinux%2Fsvntogit-community%2Fblob%2Ff3bea61b48de022cb805830979675131ab54001f%2Ftrunk%2FPKGBUILD%23L51&data=04%7C01%7Csilvano.cirujano-cuesta%40siemens.com%7Cc737e3a1217c4389673c08d8e3ef5526%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637509964371809863%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=sDJStA%2Fw7jlG3SZiDOb7sswdnpGhO1YDbxUbfIwKqaA%3D&reserved=0 >>> >>> -- System Information: >>> Debian Release: bullseye/sid >>> APT prefers testing >>> APT policy: (900, 'testing'), (50, 'unstable'), (10, 'experimental') >>> Architecture: amd64 (x86_64) >>> Foreign Architectures: i386 >>> >>> Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads) >>> 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=sh: 0: getcwd() >>> failed: No such file or directory >>> UTF-8), LANGUAGE not set >>> Shell: /bin/sh linked to /bin/dash >>> Init: systemd (via /run/systemd/system) >>> LSM: AppArmor: enabled
Bug#955619: openjdk-11-jre-headless: failure to install due to non-existant /usr/share/man/man1/ directory
On Tue, 15 Dec 2020 14:17:56 + "Daniel P. Berrange" wrote: > The postin script contains a check about whether the man page > source file exists, but doesn't check the destination directory. > > So one way to fix this problem is to change the postin script > from > > 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
Bug#985889: qemu-user-static: make binfmt setup configurable
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 binaries. * binfmt_misc configuration >From release "buster" upwards the binfmt_misc configuration being provided by this package is registering the qemu-user-static binaries with the flag "fix_binary". This configuration might be convenient in most cases (suppose that's was it's so now), but is a problem in some others. Not being able to configure binfmt_misc is a blocker for this package in the scenarios where that default configuration doesn't fit. The configuration can be changed providing different update-binfmts templates than those provided by this package and running update-binfmts. But qemu-user-static upgrades overwrite the changes. I don't know which is the best solution, but one possible is putting the update-binfmts templates now available in /usr/share/binfmts under /etc and making them configuration files (adding a .conffiles). Just for those curious when this might be an issue. Containers trying to use new syscalls not provided by the QEMU-User binaries provided by the host require newer QEMU-User binaries. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (900, 'testing'), (500, 'testing-security'), (50, 'unstable'), (10, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-4-amd64 (SMP w/4 CPU threads) 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 not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled qemu-user-static depends on no packages. Versions of packages qemu-user-static recommends: ii binfmt-support 2.2.1-1 Versions of packages qemu-user-static suggests: ii sudo 1.9.5p2-3 -- no debconf information
Bug#985889: qemu-user-static: make binfmt setup configurable
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-user-static is providing two different things
>> at once and without any declared configuration possibility (no .conffiles):
>> * QEMU-User statically linked binaries.
>> * binfmt_misc configuration
>
> Yes, it's been this way since forever.
My wording "current packaging" was biased by my wish: that future packaging
doesn't hard-code the configuration within the package :-)
>
>> From release "buster" upwards the binfmt_misc configuration being
>> provided by this package is registering the qemu-user-static binaries
>> with the flag "fix_binary". This configuration might be convenient in
>> most cases (suppose that's was it's so now), but is a problem in some
>> others.
>
>> Not being able to configure binfmt_misc is a blocker for this package in
>> the scenarios where that default configuration doesn't fit. The
>
> So far I don't see where it doesn't fit.
We have the issue that the qemu-user binaries being provided by the host don't
support some syscalls required by some of the running containers.
With the qemu-user-static configuration there's no way around it, since the
"fix_binary" flag doesn't give the container a chance to provide it's own
fitting binaries. Reconfiguring binfmt_misc not to use the "fix_binary" flag
would only survive until next qemu-user-static upgrade.
Therefore the assumption that the qemu-user binaries provided by the host will
fit ALL consumers (containers and chroots included) is wrong for us.
So the only solution is getting rid of the persistence ("fix_binary" flag) of
the host's binaries. But how?
One option is using multiarch/qemu-user-static [1], or doing pretty much the
same ourselves: letting a container change the binfmt_misc configuration of the
host! As you can imagine, that's a security risk and a source for conflicts if
having different containers with different requirements on qemu-user binaries.
I know in fact some people doing so and facing exactly these issues.
[1] https://github.com/multiarch/qemu-user-static
Another possibility is only using qemu-user binaries provided by this package
(pretty much extracting them from the package), but not the configuration and
instead use our own configuration. This solution has less drawbacks than the
previous one, but it's still a hacky workaround to return to the pre-buster
times (where the "fix_binary" flag wasn't active).
>
>
>> configuration can be changed providing different update-binfmts
>> templates than those provided by this package and running
>> update-binfmts. But qemu-user-static upgrades overwrite the changes.
>>
>> I don't know which is the best solution, but one possible is putting
>> the update-binfmts templates now available in /usr/share/binfmts under
>> /etc and making them configuration files (adding a .conffiles).
>
> It seems like way too much trouble for both the maintainer and the user.
IMO current configuration is perfectly fine as a default, but giving the users
the possibility to change it.
I don't really see where do you see the troubles for either maintainer or user.
I wonder why the configuration has to be hard-coded into a package that is
providing very valuable binaries. I'd be happy only with the binaries and being
able to provide my own configuration.
>
>> Just for those curious when this might be an issue. Containers trying to
>> use new syscalls not provided by the QEMU-User binaries provided by the host
>> require newer QEMU-User binaries.
>
> How about installing latest qemu-user-static on host instead? It is a
> self-contained package (as all binaries are statically linked). This way
> all your containers will benefit immediately, too.
Any solution involving the installation of qemu-user-static (no matter if it's
in the host or in a priviledged container) involves using exactly the same
binaries on all consumers. And as mentioned above, doesn't always fit.
>
> Thanks,
>
> /mjt
Thanks for your quick reply,
Silvano
Bug#961123: opensc: support for CardOS 5.3 broken in 0.20.0
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 `pkcs11-tool --login --test`, which reports a couple of failures in the signature verification. There's a bugfix upstream for this issue: https://github.com/OpenSC/OpenSC/pull/1987 Just for reference, here is the equivalent Fedora bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1830528 -- 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.6.0-1-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.30-8 ii libreadline8 8.0-4 ii libssl1.1 1.1.1g-1 ii opensc-pkcs11 0.20.0-4 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
