Bug#1070058: python3-gitlab: Changelog file is empty
Package: python3-gitlab
Version: 1:4.3.0-1
Severity: normal
Dear Maintainer,
The /usr/share/doc/python3-gitlab/changelog.gz is (almost) empty:
$ zcat /usr/share/doc/python3-gitlab/changelog.gz
```{include} ../CHANGELOG.md
```
That's obviously not the expected content.
This issue is present from (at least) 3.12.0-1 to 4.3.0-1
-- System Information:
Debian Release: 12.5
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-18-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr:en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages python3-gitlab depends on:
ii python33.11.2-1+b1
ii python3-requests 2.28.1+dfsg-1
ii python3-requests-toolbelt 0.10.1-1
python3-gitlab recommends no packages.
Versions of packages python3-gitlab suggests:
pn python-gitlab-doc
-- no debconf information
Bug#949969: transmission-gtk uses 100% of a CPU core
On Fri, 26 Apr 2024, Alexandre Rossi wrote: [...] > Do you see other unsual CPU usage than can be linked with very low > transfer rates? If not, I guess we can close this. Getting low transfer rates is not easy. I downloaded the Ubuntu 24.04 ISO and got ~50MB/s transfer rates and the CPU usage changed between 50 and 98%. So CPU usage seems to be lower with lower transfer rates. Once transfers slow down transmission does not take much CPU. CPU usage seems to bottom out at about 5% for slow uploads (2-4 MB/s). So I guess this can be closed. -- Francois Gouget http://fgouget.free.fr/ A particle is an irreducible representation of the Poincaré Group - Eugene Wigner
Bug#949969: transmission-gtk uses 100% of a CPU core
On Thu, 25 Apr 2024, Alexandre Rossi wrote:
> Hi,
>
> The example torrent is not available anymore.
>
> Downloading a torrent with transmission 4 from unstable does not use 100%
> CPU core.
>
> Can you reproduce?
I have upgraded to 4.0.2-1 since then and I am now using the QT client.
But using the updated torrent (see http://osm.cquest.org/torrents) top
still reports Transmission using a full core:
$ top -n1 | grep trans
10472 fgouget 20 0 3520476 328540 62496 S 118.8 1.0 330:01.80 transmi+
So 118% CPU.
But in ps the CPU usage is stuck at 3.7%:
$ ps aux | grep trans
fgouget10472 3.7 1.0 3520476 329364 ? Sl Apr19 329:41
/usr/bin/transmission-qt -session
10cae0c76f00017076185990334600170_1710862333_885767
This is while downloading the current osm.pdf.torrent file at a reported
150 MB/s average speed (1200 Mbps). While this is a 1 Gbps Internet
connection and it is indeed maxed out, that still at most 125 MB/s. So I
think the data must be compressed and transmission is reporting the
uncompressed data transfer rate.
Also now that the transfer is complete transmission is back to 0% CPU
usage.
So maybe transmission was just kept busy by the fast transfer rate?
(i7-4790K, verifying and uncompressing the data)
> Special parameters?
Nothing that I know of. I'm not limiting the download speed obviously.
Here are some possibly relevant settings from
~/.config/transmission/settings.json:
"alt-speed-enabled": false,
"cache-size-mb": 4,
"dht-enabled": true,
"encryption": 1,
"lazy-bitfield-enabled": true,
"lpd-enabled": false,
"peer-congestion-algorithm": "",
"peer-limit-global": 240,
"peer-limit-per-torrent": 60,
"peer-socket-tos": "",
"pex-enabled": true,
"port-forwarding-enabled": true,
"proxy-auth-enabled": false,
"proxy-enabled": false,
"queue-stalled-enabled": true,
"queue-stalled-minutes": 30,
"speed-limit-down-enabled": false,
"speed-limit-up-enabled": false,
"utp-enabled": true,
--
Francois Gouget http://fgouget.free.fr/
A particle is an irreducible representation of the Poincaré Group - Eugene
Wigner
Bug#1064636: libpcsclite-dev: The i386 libpcsclite-dev 2.0.1-1+b1 package conflicts with the amd64 one
On Sun, 25 Feb 2024, Ludovic Rousseau wrote: [...] > Fixed upstream in > https://github.com/LudovicRousseau/PCSC/commit/e3bfa449df5283cd7389d505399cc57d2065e637 That's great. Thanks. -- Francois Gouget http://fgouget.free.fr/ You don't liberate a people. A people liberates itself. Youssoupha
Bug#1064636: libpcsclite-dev: The i386 libpcsclite-dev 2.0.1-1+b1 package conflicts with the amd64 one
Package: libpcsclite-dev Version: 2.0.1-1+b1 Severity: normal Dear Maintainer, The 2.0.1-1+b1 version of the libpcsclite-dev broke multiarch support because the i386 /usr/share/man/man1/pcsc-spy.1.gz file differs from the amd64 one: $ zdiff -u amd64/share/man/man1/pcsc-spy.1.gz i386/share/man/man1/pcsc-spy.1.gz --- /dev/fd/5 2024-02-25 11:56:37.995245350 +0100 +++ - 2024-02-25 11:56:38.000871866 +0100 @@ -55,7 +55,7 @@ .\" .\" .IX Title "PCSC-SPY 1" -.TH PCSC-SPY 1 2024-02-23 "pcsc-lite 2.0.1" "PC/SC lite" +.TH PCSC-SPY 1 2024-02-22 "pcsc-lite 2.0.1" "PC/SC lite" .\" For nroff, turn off justification. Always turn off hyphenation; it makes .\" way too many mistakes in technical documents. .if n .ad l Maybe the build was done around midnight causing this date change. Clearly it would be best to either not include the date in the man page, or to use a source for the date that ensures it will be the same for all builds of a given version (maybe take it from the latest changelog entry?). In the meantime this makes it impossible to install both the 32-bit and 64-bit libpcsclite-dev which hampers development of the Wayland support in Wine. Regards,
Bug#1016631: reportbug: libgstreamer-plugins-base1.0-dev is not Multi-Arch compatible
This bug is still present in version 1.20.4-1. -- Francois Gouget http://fgouget.free.fr/ Vote Electronique: Les gens qui votent ne décident rien. Ceux qui comptent les votes décident de tout.
Bug#961867: #961867 python3?-talloc multiarch support is broken because of the dependency on python
Michael Tokarev wrote: > Aside of this package being M-A:same, how do you plan to *use* both > i386 and amd64 versions of this package? Sorry, I did not see that message. Anyway, I don't plan on using both i386 and amd64 versions of the python-talloc package. What I do want is to use both the i386 and amd64 versions of the samba-dev and samba-libs packages which both depend on the corresponding python3?-talloc package: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006875 So if it does indeed make no sense for python-talloc to be MultiArch: same, then I'm fine for this bug to be closed. But then it is Samba that should really be fixed. -- Francois Gouget http://fgouget.free.fr/ Good judgment comes from experience, and experience comes from bad judgment -- Barry LePatner
Bug#1016631: reportbug: libgstreamer-plugins-base1.0-dev is not Multi-Arch compatible
Package: libgstreamer-plugins-base1.0-dev Version: 1.20.3-2 Severity: normal Dear Maintainer, The libgstreamer-plugins-base1.0-dev package is not multi-arch aware so that the amd64 version conflicts with the i386 one which makes it impossible to install both. In turn this impacts Wine development as it needs to support both 32 and 64 bit Windows applications and needs libgstreamer-plugins-base1.0-dev for some of their functionality. This is a regression in 1.20.3-2. This is also not the first time libgstreamer-plugins-base1.0-dev drops multi-arch support (see bug 862119) despite it being a requirement since Debian 7. -- System Information: Debian Release: bookworm/sid APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'testing'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.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 /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libgstreamer-plugins-base1.0-dev depends on: ii gir1.2-gst-plugins-base-1.0 1.20.3-2 ii libc6-dev [libc-dev]2.33-8 ii libdrm-dev 2.4.112-3 ii libegl-dev 1.4.0-1 ii libgbm-dev 22.0.5-1 ii libgl-dev 1.4.0-1 ii libgles-dev 1.4.0-1 ii libglib2.0-dev 2.72.3-1 ii libgstreamer-gl1.0-01.20.3-2 ii libgstreamer-plugins-base1.0-0 1.20.3-2 ii libgstreamer1.0-dev 1.20.3-1 ii libgudev-1.0-dev237-2 ii liborc-0.4-dev 1:0.4.32-2 ii libwayland-dev 1.21.0-1 ii libx11-xcb-dev 2:1.7.5-1 ii pkg-config 0.29.2-1 libgstreamer-plugins-base1.0-dev recommends no packages. libgstreamer-plugins-base1.0-dev suggests no packages. -- no debconf information
Bug#1012399: fonts-vlgothic: The VL Gothic xAvgCharWidth in the OS/2 table seems wrong
Package: fonts-vlgothic Version: 20200720-1 Severity: normal Dear Maintainer, Running Wine's tests against the 20200720 VL Gothic fonts finds some inconsistencies that seem related to the xAvgCharWidth in the OS/2 table. From Wine bug 52951 [1]: Sagawa wrote: > From my viewpoint, this is a bug in font. > VL Gothic ver.20200720 has a strange xAvgCharWidth value, 958, in > OS/2 table. Generally, xAvgCharWidth is half of the unitsPerEm for > Japanese fixed-pitch font. > Previous version of VL Gothic, e.g. 20141206, had 500 xAvgCharWidth. > > I've tested the font face on Windows. It shows unnatural horizontal > spaces between Kanji characters. However, VL Gothic mainly designed > for Linux. I guess it doesn't matter on Linux. The specific Wine test failures are: font.c:4885: Test failed: expected 36 [tmAveCharWidth*2], got 19 [gmCellIncX] (VL Gothic:136 [lfCharSet]) [1] https://bugs.winehq.org/show_bug.cgi?id=52951#c1 -- System Information: Debian Release: 11.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-10-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#1011066: podman fails to run with runc due to a seccomp error
Package: podman Version: 3.0.1+dfsg1-3+deb11u1 Severity: normal Dear Maintainer, In Debian 11 podman depends on either crun or runc. However installing t with runc (which docker also depends on), results in an unusable configuration: # podman run --rm -it debian:latest Error: container_linux.go:367: starting container process caused: error adding seccomp filter rule for syscall bdflush: permission denied: OCI permission denied This error prevents 'podman run' from working, both when started from a regular account and when started as root. A fix is to install crun (and optionally uninstall runc). So either podman should be made to work with runc, or it should not accept runc as an alternative to crun. -- System Information: Debian Release: 11.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-10-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US 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.0.25+ds1-1.1 ii containernetworking-plugins 0.9.0-1+b6 ii golang-github-containers-common 0.33.4+ds1-1+deb11u1 ii init-system-helpers 1.60 ii iptables 1.8.7-1 ii libc62.31-13+deb11u3 ii libdevmapper1.02.1 2:1.02.175-2.1 ii libgpgme11 1.14.0-1+b2 ii libseccomp2 2.5.1-1+deb11u1 ii runc 1.0.0~rc93+ds1-5+b2 Versions of packages podman recommends: ii buildah 1.19.6+dfsg1-1+b6 ii fuse-overlayfs1.4.0-1 ii golang-github-containernetworking-plugin-dnsname 1.1.1+ds1-4+b7 ii slirp4netns 1.0.1-2 ii tini 0.19.0-1 ii uidmap1:4.8.1-1 Versions of packages podman suggests: pn containers-storage pn docker-compose -- Configuration Files: /etc/cni/net.d/87-podman-ptp.conflist [Errno 13] Permission non accordée: '/etc/cni/net.d/87-podman-ptp.conflist' -- no debconf information
Bug#1006875: samba-libs: The dependency on python3-talloc breaks multiarch support
Package: samba-libs Version: 2:4.13.13+dfsg-1~deb11u2 Severity: normal Dear Maintainer, samba-libs claims to support multiarch (Multiarch: same) but it depends on python3-talloc which does not support multiarch. python3-talloc seems to depend closely on the main python3 package so I am not sure it would make sense to make it multiarch. So maybe it is samba-libs that should not depend on it. Could the dependency be moved to another package which would be, for instance, multiarch=foreign? As is this prevents proper support for Samba NetAPI in 32-bit Windows applications because of this dependency chain: 32-bit Windows application -> 32-bit Wine -> 32-bit libnetapi.so -> samba-dev:i386 -> samba-libs:i386 -> python3-talloc:i386 which conflicts with python3-talloc:amd64 -- System Information: Debian Release: 11.2 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-10-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages samba-libs depends on: ii libacl1 2.2.53-10 ii libavahi-client3 0.8-5 ii libavahi-common3 0.8-5 ii libbsd0 0.11.3-1 ii libc6 2.31-13+deb11u2 ii libcap2 1:2.44-1 ii libcups2 2.3.3op2-3+deb11u1 ii libgnutls30 3.7.1-5 ii libjansson4 2.13.1-1.1 ii libldap-2.4-2 2.4.57+dfsg-3 ii libldb2 2:2.2.3-2~deb11u1 ii libnsl2 1.3.0-2 ii libpam0g 1.4.0-9+deb11u1 ii libpopt0 1.18-2 ii libpython3.9 3.9.2-1 ii libtalloc22.3.1-2+b1 ii libtdb1 1.4.3-1+b1 ii libtevent00.10.2-1 ii libwbclient0 2:4.13.13+dfsg-1~deb11u2 ii python3-ldb 2:2.2.3-2~deb11u1 ii python3-talloc2.3.1-2+b1 ii zlib1g1:1.2.11.dfsg-2 samba-libs recommends no packages. samba-libs suggests no packages. -- no debconf information
Bug#1004438: reportbug: gstreamer1.0-plugins-bad 1.18.5-1+b4 has an invalid dependency on a contrib package
Package: gstreamer1.0-plugins-bad Version: 1.18.5-1+b4 Severity: serious Justification: Policy 2.2.1 X-Debbugs-Cc: fgou...@free.fr Dear Maintainer, gstreamer1.0-plugins-bad is part of the main archive area. However in Debian Testing's version 1.18.5-1+b4 it depends on libgstreamer-gl1.0-0 which is now in the contrib archive area. This is a violation of section 2.2.1 of the Policy which states that: None of the packages in the main archive area require software outside of that area to function. So to fix this one of the following should be done: * Demote this dependency to a 'Suggest', assuming the package is still usable without it. * Remove the dependency entirely with the same caveat. * Or libgstreamer-gl1.0-0 should be moved back to the main archive area. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-10-amd64 (SMP w/36 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages gstreamer1.0-plugins-bad depends on: ii gstreamer1.0-plugins-base 1.18.5-1 ii libaom3 3.2.0-2 ii libass9 1:0.15.2-1 ii libbs2b03.1.0+dfsg-2.2+b1 ii libbz2-1.0 1.0.8-5 ii libc6 2.33-3 ii libcairo2 1.16.0-5 ii libchromaprint1 1.5.1-1 ii libcurl3-gnutls 7.81.0-1 ii libdc1394-252.2.6-4 ii libdca0 0.0.7-2 ii libde265-0 1.0.8-1 ii libdrm2 2.4.109-2 ii libdvdnav4 6.1.1-1 ii libdvdread8 6.1.2-1 ii libfaad22.10.0-2 ii libflite1 2.2-2 ii libfluidsynth3 2.2.4-2 ii libgcc-s1 11.2.0-14 ii libglib2.0-02.70.2-1 ii libgme0 0.6.3-2 ii libgsm1 1.0.18-2 ii libgstreamer-gl1.0-01.18.5-1 ii libgstreamer-plugins-bad1.0-0 1.18.5-1+b4 ii libgstreamer-plugins-base1.0-0 1.18.5-1 ii libgstreamer1.0-0 1.18.5-1 ii libgudev-1.0-0 237-2 ii libilmbase252.5.7-2 ii libkate10.4.1-11 ii liblcms2-2 2.12~rc1-2 ii liblilv-0-0 0.24.12-2 ii libltc111.3.1-1 ii libmfx1 22.1.0-1 ii libmjpegutils-2.1-0 1:2.1.0+debian-6 ii libmms0 0.6.4-3 ii libmodplug1 1:0.8.9.0-3 ii libmpcdec6 2:0.1~r495-2 ii libmpeg2encpp-2.1-0 1:2.1.0+debian-6 ii libmplex2-2.1-0 1:2.1.0+debian-6 ii libnettle8 3.7.3-1 ii libnice10 0.1.18-2 ii libofa0 0.9.3-21 ii libopenal1 1:1.19.1-2 ii libopenexr252.5.7-1 ii libopenjp2-72.4.0-6 ii libopenmpt0 0.6.0-1 ii libopenni2-02.2.0.33+dfsg-15 ii libopus01.3.1-0.1 ii liborc-0.4-01:0.4.32-2 ii libpango-1.0-0 1.50.3+ds1-4 ii libpangocairo-1.0-0 1.50.3+ds1-4 ii librsvg2-2 2.50.7+dfsg-2 ii librtmp12.4+20151223.gitfa8646d.1-2+b2 ii libsbc1 1.5-3 ii libsndfile1 1.0.31-2 ii libsoundtouch1 2.3.1+ds1-1+b1 ii libspandsp2 0.0.6+dfsg-2 ii libsrt1.4-gnutls1.4.2-1.4 ii libsrtp2-1 2.4.2-2 ii libssl1.1 1.1.1m-1 ii libstdc++6 11.2.0-14 ii libusb-1.0-02:1.0.24-3 ii libva-drm2 2.13.0-1 ii libva2 2.13.0-1 ii libvo-aacenc0 0.1.3-2 ii libvo-amrwbenc0 0.1.3-2 ii libwayland-client0 1.19.0-2+b1 ii libwebp60.6.1-2.1 ii libwebrtc-audio-processing1 0.3-1+b1 ii libwildmidi20.4.3-1 ii libx11-62:1.7.2-2+b1 ii libx265-199 3.5-2 ii libxml2 2.9.12+dfsg-5+b1 ii libzbar00.23.92-4 ii libzvbi00.2.35-19 gstreamer1.0-plugins-bad recommends no packages. Versions of packages gstreamer1.0-plugins-bad suggests: pn frei0r-plugins -- no debconf information
Bug#996858: libllvm12:i386 uninstallable and uninstall my desktop
I can confirm that it is impossible to install both the i386 and amd64 versions of libllvm12 on Debian Testing. That's because they require both packages to have the exact same versions except that they don't have the same version: 1:12.0.1-16+b1 for libllvm12:i386 1:12.0.1-16for libllvm12:amd64 >From the current debian:testing container (91e47690c6d7): # cat /etc/debian_version bookworm/sid # apt-get install libllvm12:amd64 libllvm12:i386 Reading package lists... Done Building dependency tree... Done Reading state information... Done libllvm12:i386 is already the newest version (1:12.0.1-16+b1). Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libllvm12 : Breaks: libllvm12:i386 (!= 1:12.0.1-16) but 1:12.0.1-16+b1 is to be installed libllvm12:i386 : Breaks: libllvm12 (!= 1:12.0.1-16+b1) but 1:12.0.1-16 is to be installed E: Unable to correct problems, you have held broken packages. -- Francois Gouget http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy
Bug#995777: podman: Cannot (effectively) use containers with glibc 2.33.9000 or newer
I can confirm that: * The issue is present in Debian 11 (podman3.0.1+dfsg1-3+b2), I ran into it with fedora:latest. * And the issue is fixed in Debian Testing (podman 3.4.1+ds1-2). However Debian Testing's podman is not practical to install on Debian 11 (requires a newer libc), so it would be nice if a solution could be found there. In the short term the following workaround can be used: podman run --rm --security-opt seccomp=unconfined -it fedora:latest Not sure about the security implications though. -- Francois Gouget http://fgouget.free.fr/ The last time religion ruled, it was called the dark ages.
Bug#974149: libgraphics-colorobject-perl: missing dependency on libgraphics-colornames-www-perl
I have run into this issue too with libgraphics-colorobject-perl 0.5.0-10: Can't locate Graphics/ColorNames/WWW.pm in @INC (you may need to install the Graphics::ColorNames::WWW module) (@INC contains: /home/winehq/tools/winetest /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.32.1 /usr/local/share/perl/5.32.1 /usr/lib/x86_64-linux-gnu/perl5/5.32 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.32 /usr/share/perl/5.32 /usr/local/lib/site_perl) at /usr/share/perl5/Graphics/ColorObject.pm line 2093. BEGIN failed--compilation aborted at /usr/share/perl5/Graphics/ColorObject.pm line 2093. -- Francois Gouget http://fgouget.free.fr/ All generalizations are false, including this one. -- Mark Twain
Bug#992066: libvkd3d-headers: Package doesn't contain header files
I can confirm this. None of the 1.2-5 vkd3d packages contain the headers: particularly not libvkd3d-headers and not libvkd3d-dev. The workaround is to go back to vkd3d 1.2-3 (if you can find the corresponding packages that is). -- Francois Gouget http://fgouget.free.fr/ The greatest programming project of all took six days; on the seventh day the programmer rested. We've been trying to debug the *&^%$#@ thing ever since. Moral: design before you implement.
Bug#983776: libvkd3d-dev 1.2-3 breaks multi-arch support
On Tue, 16 Mar 2021, Sveinar Søpler wrote: [...] > > The output produced by i386 and amd64 (or any other, for that matter) builds > > of vkd3d-compiler should be identical; if it isn't, that would be considered > > a bug. For the record, I would be inclined to agree that the -dev package is > > not the appropriate place for vkd3d-compiler. > > How would vkd3d-compiler be identical regardless of arch? It's not vkd3d-compiler that's identical regardless of arch. It's the output of vkd3d-compiler which is. What this means is it makes sense to put vkd3d-compiler in its own package with Multi-Arch: foreign. -- Francois Gouget http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.
Bug#983776: libvkd3d-dev 1.2-3 breaks multi-arch support
On Wed, 3 Mar 2021, Sveinar Søpler wrote: > I actually ended up generating a "vkd3d-tools" package for my Ubuntu > PPA packages with this binary set to Multi-Arch: no Should that actually be Multi-Arch: foreign? Just asking. I don't actually know if the 32- and 64-bit vkd3d-compiler produce identical files or if one produces 32-bit files and the other 64-bit ones. If the latter then following the gcc naming scheme would probably make sense. -- Francois Gouget http://fgouget.free.fr/ Indifference will certainly be the downfall of mankind, but who cares?
Bug#983776: libvkd3d-dev 1.2-3 breaks multi-arch support
Package: libvkd3d-dev Version: 1.2-3 Severity: normal libvkd3d-dev 1.2-3 ships the architecture-dependent /usr/bin/vkd3d-compiler file which is incompatible with "Multi-Arch: same". So as is the package is invalid. Multiarch support in vkd3d is really needed though because Wine depends on it as Windows applications come in both 32-bit and 64-bit flavors. So lack of multiarch support in vkd3d prevents Wine from having D3D12 support in either its 32- or 64-bit versions thus making development much harder. -- System Information: Debian Release: 10.8 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-14-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libvkd3d-dev depends on: ii libc6 2.28-10 ii libvkd3d-shader1 1.2-3 ii libvkd3d-utils1 1.2-3 ii libvkd3d1 1.2-3 libvkd3d-dev recommends no packages. libvkd3d-dev suggests no packages. -- no debconf information
Bug#973798: xdg-utils: xdg-open fails to open file://localhost/xxx URLs
Package: xdg-utils Version: 1.1.3-2 Severity: normal Tags: patch Dear Maintainer, $ echo Hello >/tmp/foo.html $ xdg-open file://localhost/tmp/foo.html Unable to run the command specified. The file or folder //localhost/tmp/foo.html does not exist. $ xdg-open file:///tmp/foo.html -> open foo.html as expected. Normally file:///tmp/foo.html and file://localhost/tmp/foo.html are equivalent URLs. Note that this is fixed upstream in the commit below: commit 186966735dcccd61afde937118f27043bd084f57 Author: Richard Tollerton Date: Thu Jan 10 15:41:08 2019 -0600 xdg-open: handle file://localhost/ Presently, file://localhost/ URLs are totally unsupported: is_file_url_or_path correctly considers them files, but they are undecoded and hence check_input_file fails. While the standardization surrounding file: URLs is admittedly vague [1], AFAIK, *all* literature, and other implementations, unambiguously demonstrate that file://localhost/ should be equivalent to file:///: - The "File URI specification" explicitly linked to from the xdg-utils homepage [2] - RFC 8089 section 1.1 - RFC 1738 section 3.10 - Observed implementations of Windows `start`, macOS `open`, Firefox, Chrome, IE Fix this by adding some simple carve-outs for file://localhost specifically in file_url_to_path. [1] https://lists.freedesktop.org/archives/xdg/2004-November/003711.html [2] https://edeproject.org/spec/file-uri-spec.txt Signed-off-by: Richard Tollerton -- Package-specific info: Desktop environment: XDG_CURRENT_DESKTOP=KDE -- System Information: Debian Release: 10.6 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-11-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled xdg-utils depends on no packages. Versions of packages xdg-utils recommends: ii libfile-mimeinfo-perl 0.29-1 ii libnet-dbus-perl 1.1.0-5+b1 ii libx11-protocol-perl 0.56-7 ii x11-utils 7.7+4 ii x11-xserver-utils 7.7+8 xdg-utils suggests no packages. -- no debconf information
Bug#970323: dpkg-deb fails to create package > 2 GB
On Tue, 15 Sep 2020, Guillem Jover wrote: [...] > From the error message printed, it looks like your temporary directory > is not big enough. If you set TMPDIR to something else it should work > I guess? Argh! That's it. Sorry for missing it. The bug can be closed then. -- Francois Gouget
Bug#970323: dpkg-deb fails to create package > 2 GB
Package: dpkg Version: 1.19.7 Severity: normal Dear Maintainer, dpkg-deb fails to create a package with a size greater than 2 GB. To reproduce this issue use the attached file to create a 2.4 GB package, this despite being on a 64-bit system: $ tar xfz testpkg.tar.gz $ cd testpkg $ fakeroot ./build [...] + dh_builddeb --destdir=. dpkg-deb: building package 'testpkg' in './testpkg_1.0-1_all.deb'. dpkg-deb (subprocess): compressing tar member: lzma write error: No space left on device dpkg-deb: error: from tar -cf subprocess returned error exit status 2 dh_builddeb: dpkg-deb --build debian/testpkg . returned exit code 2 dh_builddeb: Aborting due to earlier error Note that neither tar nor ar have any trouble dealing with archives with a size greater than 2 GB. Also this is not specific to the lzma compressor: using gzip instead produces the same error. -- Package-specific info: -- System Information: Debian Release: 10.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-10-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dpkg depends on: ii libbz2-1.0 1.0.6-9.2~deb10u1 ii libc62.28-10 ii liblzma5 5.2.4-1 ii libselinux1 2.8-1+b1 ii tar 1.30+dfsg-6 ii zlib1g 1:1.2.11.dfsg-1 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt1.8.2.1 pn debsig-verify -- no debconf information testpkg.tar.gz Description: application/gzip
Bug#968713: tiger complains about unknown nsfs filesystem
Package: tiger Version: 1:3.2.4~rc1-2 Severity: normal Dear Maintainer, tiger complains about finding an unknown filesystem: --CONFIG-- [con010c] Filesystem 'nsfs' used by 'nsfs' is not recognised as a valid filesystem nsfs is the "Name Space File System" used by the setns() system call. It is used by snap and docker among others. -- System Information: Debian Release: 10.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-0.bpo.2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tiger depends on: ii binutils 2.31.1-16 ii bsdmainutils 11.1.2+b1 ii debconf [debconf-2.0] 1.5.71 ii libc6 2.28-10 ii net-tools 1.60+git20180626.aebd88e-1 ii ucf3.0038+nmu1 Versions of packages tiger recommends: ii chkrootkit 0.52-3+b10 ii exim4-daemon-light [mail-transport-agent] 4.92-8+deb10u4 ii john 1.8.0-2+b1 pn tripwire | aide Versions of packages tiger suggests: ii lsof 4.91+dfsg-1 pn lynis -- debconf information excluded
Bug#961867: python3?-talloc multiarch support is broken because of the dependency on python
Package: python-talloc Version: 2.1.14-2 Severity: normal Dear Maintainer, python-talloc is 'multiarch: same' but the i386 package is not coinstallable with the amd64 one because of their python dependency. The issue is that python-talloc:i386 depends on python:i386, while python-talloc:amd64 depends on python:amd64. But python is multiarch allowed and this causes a conflict when trying to install both i386 and amd64. python3-talloc 2.3.0-5 has the same issue in Debian Testing but with python3 instead of python. Maybe what was intended is to have a python3:any dependency instead of a regular python3 one? So this would make it: Depends: libtalloc2 (= 2.3.0-5), python3:any (<< 3.9), python3:any (>= 3.8~), libc6 (>= 2.4), libpython3.8 (>= 3.8.2) Unfortunately I don't know enough about python3-talloc to know if that would make sense. This multiarch howto section seems particularly relevant: https://wiki.debian.org/Multiarch/HOWTO#When_to_use_:native_and_when_to_use_:any.3F The impact is that this prevents Wine from using the libnetapi library for 32-bit Windows applications because libnetapi is part of samba-libs, which depends on python3-talloc. -- System Information: Debian Release: 10.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-8-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python-talloc depends on: ii libc6 2.28-10 ii libpython2.7 2.7.16-2+deb10u1 ii libtalloc22.1.14-2 ii python2.7.16-1 python-talloc recommends no packages. python-talloc suggests no packages. -- no debconf information
Bug#933713: libgpg-error-dev: make package fit for cross development
On Wed, 12 Feb 2020, Daniel Kahn Gillmor wrote:
> On Tue 2020-01-28 13:01:04 +0100, Francois Gouget wrote:
[...]
> > So I think it is reasonable to stop shipping gpg-error-config, just like
> > FreeType stopped shipping freetype-config to become multiarch-compatible.
>
> I agree that upstream's preferred configuration mechanism
> (gpg-error-config) is not well-suited for the modern multiarch world.
But is gpg-error-config upstream's _preferred_ configuration mechanism
or merely the legacy one?
> That said, I'm not convinced that removal of upstream's preferred
> configuration mechanism in debian is a great idea. Have you
> successfully built (for example) libgcrypt or the other reverse
> dependencies in debian against such a modified package?
I did not try. But any package that depends on a multiarch-incompatible
xxx-config script is broken imho.
Now an alternative to removing gpg-error-config is to make it
compatible with multiarch. The only differences between the two copies
are:
-libdir=${prefix}/lib/x86_64-linux-gnu
+libdir=${prefix}/lib/i386-linux-gnu
...
- output="$output -L${prefix}/lib/x86_64-linux-gnu -lgpg-error"
+ output="$output -L${prefix}/lib/i386-linux-gnu -lgpg-error"
The -L option is not needed on Debian so it might as well be omitted.
- host) echo "x86_64-pc-linux-gnu" ;;
+ host) echo "i686-pc-linux-gnu" ;;
...
-echo "x86_64-pc-linux-gnu"
+echo "i686-pc-linux-gnu"
This one is the real problem. Maybe it can be derived from some other
source. Or maybe removing support for host would have less impact than
removing gpg-error-config entirely.
> > libgcrypt is under consideration for use in Wine but Wine depends on
> > proper multiarch support since we need to support both 32 bit and 64 bit
> > Windows applications (even 64 bit Windows applications have 32 bit
> > installers).
>
> What other encryption libraries has Wine considered for the purposes it
> is considering libgcrypt for? Nettle should have comparable licensing
> concerns, a similar spread of cryptographic primitives covered, and a
> more idiomatic C interface (algortihm-specific structs, no
> S-expression string management, etc)
Wine normally uses GnuTLS. But GnuTLS is missing support for ECDH public
key encryption. From the patch that triggered this:
https://www.winehq.org/pipermail/wine-devel/2020-January/157434.html
+/* this is necessary since GNUTLS doesn't support ECDH public key encryption,
maybe we can replace this when it does:
+
https://github.com/gnutls/gnutls/blob/cdc4fc288d87f91f974aa23b6e8595a53970ce00/lib/nettle/pk.c#L495
*/
For now this patchset is on hold to not add a new dependency to Wine.
--
Francois Gouget http://fgouget.free.fr/
f u kn rd ts, ur wy 2 gky 4 ur wn gd.
Bug#952768: libxslt1-dev amd64 and i386 no longer multi-arch coinstallable
I propose the following patch which simply removes xslt-config on account of the xxx-config scripts being relics from a faraway pre-pkgconfig past and having for sole purpose to break multiarch compatibility. In that view any package which depends on an xxx-config script is broken and should be fixed to use pkgconfig instead. There is another trap which is that the package is missing a Build-Depends on xsltproc, resulting in differences in the NEWS file depending on whether the build machine (or chroot) has it installed or not! A proper fix would probably be to use the freshly built xsltproc binary instead of hardcoding /usr/bin/xsltproc but I'll just leave that as an exercise for the reader. diff -ur debian.orig/changelog debian/changelog --- debian.orig/changelog 2020-02-22 15:28:46.0 +0100 +++ debian/changelog2020-03-04 12:00:00.0 +0100 @@ -1,3 +1,11 @@ +libxslt (1.1.34-3ma) unstable; urgency=medium + + * Remove xslt-config for multiarch compatibility. Closes: #952768 + * Add a build dependency on xsltproc because it is needed to update the +NEWS file. + + -- Francois Gouget Wed, 04 Mar 2020 12:00:00 +0100 + libxslt (1.1.34-3) unstable; urgency=medium * Team upload. diff -ur debian.orig/control debian/control --- debian.orig/control 2020-02-22 15:23:43.0 +0100 +++ debian/control 2020-03-04 12:00:00.0 +0100 @@ -13,6 +13,7 @@ perl:any, pkg-config, rename, + xsltproc, Standards-Version: 4.5.0 Rules-Requires-Root: no Homepage: http://xmlsoft.org/xslt/ diff -ur debian.orig/libxslt1-dev.install debian/libxslt1-dev.install --- debian.orig/libxslt1-dev.install2020-02-21 14:18:51.0 +0100 +++ debian/libxslt1-dev.install 2020-03-04 11:53:24.0 +0100 @@ -1,4 +1,3 @@ -usr/bin/xslt-config usr/include usr/lib/*/libexslt.so usr/lib/*/libxslt.so -- Francois Gouget http://fgouget.free.fr/ Hell is empty and all the devils are here. -- Wm. Shakespeare, "The Tempest"
Bug#952768: libxslt1-dev amd64 and i386 no longer multi-arch coinstallable
Wine requires being able to build both 32 bit and 64 bit binaries in order to handle 64 bit Windows applications and their 32 bit installers. So this regression breaks Wine development on Debian Testing. -- Francois Gouget http://fgouget.free.fr/ E-Voting: Those who cast the votes decide nothing. Those who count the votes decide everything.
Bug#933713: libgpg-error-dev: make package fit for cross development
Package: libgpg-error-dev
Version: 1.36-7
Followup-For: Bug #933713
libgcrypt is under consideration for use in Wine but Wine depends on
proper multiarch support since we need to support both 32 bit and 64 bit
Windows applications (even 64 bit Windows applications have 32 bit
installers).
This means a Wine developer needs to install both the i386 and amd64
variants of libgcrypt-dev which in turn depends on libgpg-error-dev.
Some libgpg-error-dev's lack of multiarch support prevents Wine from
using libgcrypt.
The only blocker for making libgpg-error-dev Multi-Arch: same is
gpg-error-config. However gpg-error-config is not needed on Debian
since there is no need for -I or -L directives; and it has been
superseded by gpgrt-config and pkgconfig anyway.
So I think it is reasonable to stop shipping gpg-error-config, just like
FreeType stopped shipping freetype-config to become multiarch-compatible.
The attached patch modifies libgpg-error-dev accordingly. Feel free to
incorporate it into a future release and to adjust the changelog as you
see fit.
In the meantime one can generate multiarch-ified packages as follows:
(you'll probably need to create a 32 bit chroot with debootstrap+schroot)
tar xfj libgpg-error_1.36.orig.tar.bz2
cd libgpg-error-1.36
tar xfJ ../libgpg-error_1.36-7.debian.tar.xz
patch -p1 <../libgpg-error.diff
dpkg-buildpackage -rfakeroot -uc -us
diff -ur '--exclude=*~' libgpg-error-1.36.orig/debian/changelog
libgpg-error-1.36/debian/changelog
--- libgpg-error-1.36.orig/debian/changelog 2019-07-16 19:32:03.0
+0200
+++ libgpg-error-1.36/debian/changelog 2020-01-28 12:19:50.920379927 +0100
@@ -1,3 +1,12 @@
+libgpg-error (1.36-7m) unstable; urgency=medium
+
+ * Don't ship gpg-error-config: it is not needed on Debian, has been
+superseeded by gpgrt-config and pkgconfig and is incompatible with
+multiarch support
+ * Mark the development package as multiarch (Closes: #933713)
+
+ -- Francois Gouget Tue, 28 Jan 2020 02:02:00 +0100
+
libgpg-error (1.36-7) unstable; urgency=medium
* d/tests/windows: specify WINESERVER
diff -ur '--exclude=*~' libgpg-error-1.36.orig/debian/control
libgpg-error-1.36/debian/control
--- libgpg-error-1.36.orig/debian/control 2019-07-14 18:59:16.0
+0200
+++ libgpg-error-1.36/debian/control2020-01-28 04:11:55.027998272 +0100
@@ -20,6 +20,7 @@
Package: libgpg-error-dev
Section: libdevel
Architecture: any
+Multi-Arch: same
Depends:
libgpg-error0 (= ${binary:Version}),
${misc:Depends},
diff -ur '--exclude=*~'
libgpg-error-1.36.orig/debian/libgpg-error-dev.install.in
libgpg-error-1.36/debian/libgpg-error-dev.install.in
--- libgpg-error-1.36.orig/debian/libgpg-error-dev.install.in 2018-12-15
02:54:26.0 +0100
+++ libgpg-error-1.36/debian/libgpg-error-dev.install.in2020-01-28
11:21:52.852522535 +0100
@@ -1,4 +1,3 @@
-usr/bin/gpg-error-config
usr/bin/gpgrt-config
usr/include/* usr/include/@DEB_HOST_MULTIARCH@/
usr/lib/*/libgpg-error.a
Bug#949969: transmission-gtk uses 100% of a CPU core
Package: transmission-gtk Version: 2.94-2 Severity: normal Dear Maintainer, When running transmission-gtk with two torrents it uses 100% of a CPU core: fgouget 24435 98.9 0.2 814620 67712 ?Sl 17:36 2:11 /usr/bin/transmission-gtk fgouget 24435 98.9 0.2 814620 67712 ?Sl 17:36 2:12 /usr/bin/transmission-gtk fgouget 24435 99.0 0.2 814620 67712 ?Sl 17:36 2:13 /usr/bin/transmission-gtk For both torrents the download speed is capped to 100 KB/s and neither is uploading to anyone. * Pausing both torrents does not lead to a reduction of the CPU usage. * After exiting and restarting Transmission with both torrents still paused it uses under 1% of CPU. But restarting either torrent causes transmission-gtk to slowly go back up to 100% CPU usage again. * Removing the download speed limit makes no difference. * Keeping just one torrent does not help either. * Then I suspended the torrent, restarted transmission-gtk, told it to verify the local data, waited until that was done, and then restarted the torrent with a 100 KB/s download limit and CPU usage still rose to 83% (not 100% this time). * Running transmission-cli on the torrent saved by transmission-gtk results in it using 100% CPU too. So the bug may be in the transmission-common package. * Here's the one torrent I kept (~50GB): http://osm.cquest.org/torrents/planet-200120.osm.pbf.torrent -- System Information: Debian Release: 10.2 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages transmission-gtk depends on: ii libayatana-appindicator3-1 0.5.3-4 ii libc6 2.28-10 ii libcurl47.64.0-4 ii libevent-2.1-6 2.1.8-stable-4 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-02.58.3-2+deb10u2 ii libgtk-3-0 3.24.5-1 ii libminiupnpc17 2.1-1+b1 ii libnatpmp1 20150609-7 ii libpango-1.0-0 1.42.4-7~deb10u1 ii libssl1.1 1.1.1d-0+deb10u2 ii transmission-common 2.94-2 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages transmission-gtk recommends: ii xdg-utils 1.1.3-1 transmission-gtk suggests no packages. -- no debconf information
Bug#888711: fail2ban fails to start sshd-ddos filter.
Package: fail2ban Version: 0.10.2-2.1 Followup-For: Bug #888711 Dear Maintainer, fail2ban 0.10.2-2.1 still ships the incorrect sshd-ddos.conf and sshd-aggressive.conf files. Neither ddos nor aggressive are defined parameters so these files should be rewritten as shown in the attachements, that is by simply setting mode to the desired value: mode = ddos and mode = aggressive respectively. -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fail2ban depends on: ii lsb-base 10.2019051400 ii python3 3.7.3-1 Versions of packages fail2ban recommends: ii iptables 1.8.2-4 ii nftables 0.9.0-2 ii python 2.7.16-1 ii python3-pyinotify 0.9.6-1 ii python3-systemd234-2+b1 ii whois 5.4.3 Versions of packages fail2ban suggests: ii bsd-mailx [mailx]8.1.2-0.20180807cvs-1 ii mailutils [mailx]1:3.5-3 pn monit ii rsyslog [system-log-daemon] 8.1901.0-1 ii sqlite3 3.27.2-3 -- Configuration Files: /etc/fail2ban/filter.d/sshd-aggressive.conf changed: [INCLUDES] before = sshd.conf [Definition] mode = aggressive /etc/fail2ban/filter.d/sshd-ddos.conf changed: [INCLUDES] before = sshd.conf [Definition] mode = ddos -- no debconf information
Bug#873845: fail2ban-regex does not match with default sshd-ddos filter
Package: fail2ban
Version: 0.10.2-2.1
Followup-For: Bug #873845
Dear Maintainer,
This attack is in active use right now and this TWO YEARS OLD bug is
preventing fail2ban from doing anything about it!
Jul 19 06:59:33 amibe sshd[32728]: Did not receive identification string from
47.96.156.238 port 54886
Jul 19 07:00:21 amibe sshd[1320]: Invalid user nathan from 47.96.156.238 port
58080
Jul 19 07:00:21 amibe sshd[1320]: pam_unix(sshd:auth): authentication failure;
logname= uid=0 euid=0 tty=ssh ruser= rhost=47.96.156.238
Jul 19 07:00:23 amibe sshd[1320]: Failed password for invalid user nathan from
47.96.156.238 port 58080 ssh2
Jul 19 07:10:29 amibe sshd[6777]: Connection closed by 47.96.156.238 port 43090
[preauth]
The current OpenSSH server may not be vulnerable to this attack but this
is a missed opportunity for blocking the attacker before it switches to
plain password scanning as shown above.
And yet the fix is very simple, just allow the presence of the source
port at the end of the log line:
(from /etc/fail2ban/filter.d/sshd.conf)
mdre-ddos = ^Did not receive identification string from
%(__suff)s%(__on_port_opt)s$
Note that __on_port_opt matches 0 or more characters so this does not
prevent the regexp from matching log lines that don't include the source
port number.
-- System Information:
Debian Release: 10.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr:en_US (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages fail2ban depends on:
ii lsb-base 10.2019051400
ii python3 3.7.3-1
Versions of packages fail2ban recommends:
ii iptables 1.8.2-4
ii nftables 0.9.0-2
ii python 2.7.16-1
ii python3-pyinotify 0.9.6-1
ii python3-systemd234-2+b1
ii whois 5.4.3
Versions of packages fail2ban suggests:
ii bsd-mailx [mailx]8.1.2-0.20180807cvs-1
ii mailutils [mailx]1:3.5-3
pn monit
ii rsyslog [system-log-daemon] 8.1901.0-1
ii sqlite3 3.27.2-3
-- Configuration Files:
/etc/fail2ban/fail2ban.conf changed:
[Definition]
loglevel = INFO
logtarget = /var/log/fail2ban.log
syslogsocket = auto
socket = /var/run/fail2ban/fail2ban.sock
pidfile = /var/run/fail2ban/fail2ban.pid
dbfile = /var/lib/fail2ban/fail2ban.sqlite3
dbpurgeage = 7d
/etc/fail2ban/filter.d/sshd.conf changed:
[INCLUDES]
before = common.conf
[DEFAULT]
_daemon = sshd
__pref = (?:(?:error|fatal): (?:PAM: )?)?
__suff = (?: \[preauth\])?\s*
__on_port_opt = (?: port \d+)?(?: on \S+(?: port \d+)?)?
__alg_match = (?:(?:\w+ (?!found\b)){0,2}\w+)
[Definition]
prefregex =
^%(__prefix_line)s%(__pref)s.+$
cmnfailre = ^[aA]uthentication (?:failure|error|failed) for .*
from ( via \S+)?\s*%(__suff)s$
^User not known to the underlying authentication module for
.* from \s*%(__suff)s$
^Failed \S+ for invalid user (?P\S+)|(?:(?! from
).)*? from %(__on_port_opt)s(?: ssh\d*)?(?(cond_user):
|(?:(?:(?! from ).)*)$)
^Failed \b(?!publickey)\S+ for (?Pinvalid user
)?(?P\S+)|(?(cond_inv)(?:(?! from ).)*?|[^:]+) from
%(__on_port_opt)s(?: ssh\d*)?(?(cond_user): |(?:(?:(?! from ).)*)$)
^ROOT LOGIN REFUSED.* FROM \s*%(__suff)s$
^[iI](?:llegal|nvalid) user .*? from
%(__on_port_opt)s\s*$
^User .+ from not allowed because not
listed in AllowUsers\s*%(__suff)s$
^User .+ from not allowed because listed in
DenyUsers\s*%(__suff)s$
^User .+ from not allowed because not in
any group\s*%(__suff)s$
^refused connect from \S+ \(\)\s*%(__suff)s$
^Received disconnect from
%(__on_port_opt)s:\s*3: .*: Auth fail%(__suff)s$
^User .+ from not allowed because a group
is listed in DenyGroups\s*%(__suff)s$
^User .+ from not allowed because none of
user's groups are listed in AllowGroups\s*%(__suff)s$
^pam_unix\(sshd:auth\):\s+authentication
failure;\s*logname=\S*\s*uid=\d*\s*euid=\d*\s*tty=\S*\s*ruser=\S*\s*rhost=\s.*%(__suff)s$
^(error: )?maximum authentication attempts exceeded for
.* from %(__on_port_opt)s(?: ssh\d*)?%(__suff)s$
^User .+ not allowed because account is
locked%(__suff)s
^Disconnecting: Too many authentication
failures(?: for .+?)?%(__suff)s
^Received
disconnect from : 11:
^Connection closed
by %(__suff)s$
^Accepted publickey
for \S+ from (?:\s|$)
mdre-normal =
mdre-ddos = ^Did not receive identification string from
%(__suff)s%(__on_port_opt)s$
^Connection reset by
%(__on_port_opt)s%(__suff)s
^SSH: Server;Ltype:
Bug#924449: lintian: Periodic "out of disk space" errors from lindsay.d.o
On Fri, 5 Jul 2019, Felix Lechner wrote: > Hi François, > > On Fri, Jul 5, 2019 at 2:03 AM Francois Gouget wrote: > > > > I'm also running into "out of disk space" errors caused by Lintian. > > These happen when I check a 240 MB package > > Would you please provide a link to this package? Sorry. It's a proprietary package so I can't. I investigated some more and the issue I'm seeing may have nothing to do with this bug. The portion of the Lintian lab that takes all the space is where the package gets unpacked. I have a script that does a bunch of builds and among then one is a debug version of the package with unstripped binaries. Of course that package is bigger and some libraries have been added recently which has only increased its size. The result is that once unpacked it takes about 1.4 GB. Still not enough to fill /tmp's 2 GB but getting close enough if it's partially full already I guess. So for now I think it's reasonable to chalk it up to that and ignore what I said before. -- Francois Gouget http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, it's computer science.
Bug#924449: lintian: Periodic "out of disk space" errors from lindsay.d.o
I'm also running into "out of disk space" errors caused by Lintian. These happen when I check a 240 MB package because lintian fills /tmp which, being on a tmpfs filesystem as is the default on Debian (as far as I know) only has about 2 GB of available space. tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime,size=2097152k) For now I've been working around this issue by setting TMPDIR=/var/tmp but using 1.9+ GB to check a 0.2 GB package seems a bit much. -- Francois Gouget http://fgouget.free.fr/ Hiroshima '45 - Czernobyl '86 - Windows '95
Bug#931446: lintian: corrections-case contains invalid lines
Package: lintian Version: 2.15.0 Severity: normal Dear Maintainer, /usr/share/lintian/data/spelling/corrections-case contains some invalid lines. That file's format is described in the initial comment: # The format of each line is: # mistake||correction But lintian 2.15.0 contains the following lines which are missing a pipe: wi-fi|Wi-Fi wifi|Wi-Fi Wi-fi|Wi-Fi Wifi|Wi-Fi WiFi|Wi-Fi -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils 2.31.1-16 ii bzip2 1.0.6-9.1 ii diffstat 1.62-1 ii dpkg 1.19.7 ii dpkg-dev 1.19.7 ii file 1:5.35-4 ii gettext0.19.8.1-9 ii gpg2.2.12-1 ii intltool-debian0.35.0+20060710.5 ii libapt-pkg-perl0.1.34+b1 ii libarchive-zip-perl1.64-1 ii libcapture-tiny-perl 0.48-1 ii libcgi-pm-perl 4.40-1 ii libclass-accessor-perl 0.51-1 ii libclone-perl 0.41-1+b1 ii libdigest-sha-perl 6.02-1+b1 ii libdpkg-perl 1.19.7 ii libemail-valid-perl1.202-1 ii libfile-basedir-perl 0.08-1 ii libio-async-perl 0.72-1 ii libipc-run-perl20180523.0-1 ii liblist-moreutils-perl 0.416-1+b4 ii libparse-debianchangelog-perl 1.2.0-13 ii libpath-tiny-perl 0.108-1 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3000-2 ii libtry-tiny-perl 0.30-1 ii liburi-perl1.76-1 ii libxml-simple-perl 2.25-1 ii libyaml-libyaml-perl 0.76+repack-1 ii man-db 2.8.5-2 ii patchutils 0.3.4-2 ii perl 5.28.1-6 ii t1utils1.41-3 ii xz-utils 5.2.4-1 Versions of packages lintian recommends: ii libperlio-gzip-perl 0.19-1+b5 Versions of packages lintian suggests: ii binutils-multiarch 2.31.1-16 ii libhtml-parser-perl3.72-3+b3 pn libtext-template-perl -- no debconf information
Bug#927900: qemu-system-x86_64 crashes when using GStreamer
Package: qemu-system-x86 Version: 1:3.1+dfsg-7 Severity: normal Dear Maintainer, To reproduce: * Create a VM using Spice. * Tell QEmu to stream all videos by using virsh to add the streaming mode setting like so: * Start the VM and play a video in the guest. For instance: mplayer big_buck_bunny_1080p_h264.mov As soon as QEmu switches the video to streaming mode it will crash. In the log the last lines are: (qemu-system-x86_64:6140): GStreamer-WARNING **: 16:13:21.872: External plugin loader failed. This most likely means that the plugin loader helper binary was not found or could not be run. You might need to set the GST_PLUGIN_SCANNER environment variable if your setup is unusual. This should normally not be required though. 2019-04-24 14:13:22.569+: shutting down, reason=crashed Notes: * This happens with and without apparmor installed so this is not an issue caused by apparmor preventing GStreamer from finding the files it needs. * I can use video streaming just fine in Xspice so the bug is most likely not in the libspice-server libraries. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages qemu-system-x86 depends on: ii ipxe-qemu 1.0.0+git-20190125.36a4c85-1 ii libaio1 0.3.112-3 ii libasound21.1.8-1 ii libbluetooth3 5.50-1 ii libbrlapi0.6 5.6-10 ii libc6 2.28-8 ii libcacard01:2.6.1-1 ii libcapstone3 4.0.1+really+3.0.5-1 ii libepoxy0 1.5.3-0.1 ii libfdt1 1.4.7-3 ii libgbm1 18.3.4-2 ii libgcc1 1:8.3.0-6 ii libglib2.0-0 2.58.3-1 ii libgnutls30 3.6.6-2 ii libibverbs1 22.1-1 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libncursesw6 6.1+20181013-2 ii libnettle63.4.1-1 ii libnuma1 2.0.12-1 ii libpixman-1-0 0.36.0-1 ii libpng16-16 1.6.36-5 ii librdmacm122.1-1 ii libsasl2-22.1.27+dfsg-1 ii libseccomp2 2.3.3-4 ii libspice-server1 0.14.0-1.3 ii libtinfo6 6.1+20181013-2 ii libusb-1.0-0 2:1.0.22-2 ii libusbredirparser10.8.0-1 ii libvdeplug2 2.3.2+r586-2.2 ii libvirglrenderer0 0.7.0-2 ii libxendevicemodel14.11.1+26-g87f51bf366-3 ii libxenevtchn1 4.11.1+26-g87f51bf366-3 ii libxenforeignmemory1 4.11.1+26-g87f51bf366-3 ii libxengnttab1 4.11.1+26-g87f51bf366-3 ii libxenmisc4.114.11.1+26-g87f51bf366-3 ii libxenstore3.04.11.1+26-g87f51bf366-3 ii libxentoolcore1 4.11.1+26-g87f51bf366-3 ii qemu-system-common1:3.1+dfsg-7 ii qemu-system-data 1:3.1+dfsg-7 ii seabios 1.12.0-1 ii zlib1g1:1.2.11.dfsg-1 Versions of packages qemu-system-x86 recommends: ii ovmf 0~20181115.85588389-3 ii qemu-system-gui 1:3.1+dfsg-7 ii qemu-utils 1:3.1+dfsg-7 Versions of packages qemu-system-x86 suggests: pn qemu-block-extra ii samba 2:4.9.5+dfsg-3 ii sgabios 0.0~svn8-4 ii vde2 2.3.2+r586-2.2 -- no debconf information
Bug#835466: xserver-xorg-core: Xorg incorrectly switches vt when exiting Xspice
This issue is still present in xserver-xorg-core 2:1.20.3-1. The workaround is to specify the virtual console the current X server runs on. So if it is running on vt7, use a command line of the form: /usr/lib/xorg/Xorg -config myxspice.conf -noreset vt7 :1.0 I guess the reason it works is because it causes Xorg to switch to what is already the current virtual console. -- Francois Gouget http://fgouget.free.fr/ A black hole is just God dividing by zero.
Bug#815724: libnet-ssh2-perl: Public key authentication fails when key generated with -a
Before the first step one should do: cd ~/.ssh Three years later this bug is still present. I guess that makes sense since the last changelog entry for libssh2 goes back to october 2016! Fortunately there is a workaround: add this use statement right before the "use Net::SSH2" line: use Net::OpenSSH::Compat::SSH2 qw(:supplant); This causes the script to use Net::OpenSSH which actually works. Unfortunately this workaround will not work for all scripts but migrating to Net::OpenSSH is still a good idea to avoid Net::SSH2's compatibility and maintenance issues. -- Francois Gouget http://fgouget.free.fr/ Theory is where you know everything but nothing works. Practice is where everything works but nobody knows why. Sometimes they go hand in hand: nothing works and nobody knows why.
Bug#923729: mysql-workbench: Cannot satisfy the gdal-abi-2-3-0 dependency
Package: mysql-workbench Version: 6.3.10+dfsg-3 Severity: normal Dear Maintainer, mysql-workbench 6.3.10+dfsg-3 depends on gdal-abi-2-3-0. Debian Stable only has the older gdal-abi-2-1-2 provided by libgdal20 2.1.2+dfsg-5, while newer distributions (Testing and Unstable) only have the newer gdal-abi-2-4-0 provided by libgdal20 2.4.0+dfsg-1. So as is mysql-workbench 6.3.10+dfsg-3 cannot be installed on any Debian distribution. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mysql-workbench depends on: pn gdal-abi-2-1-2 pn gdal-abi-2-3-0 ii libatkmm-1.6-1v5 2.28.0-2 ii libc62.28-7 ii libcairo21.16.0-2 ii libcairomm-1.0-1v5 1.12.2-4 pn libctemplate3 ii libgcc1 1:8.2.0-21 pn libgdal20 ii libgdk-pixbuf2.0-0 2.38.0+dfsg-7 ii libgl1 1.1.0-1 ii libgl1-mesa-glx 18.3.4-1 ii libglib2.0-0 2.58.3-1 ii libglibmm-2.4-1v52.58.0-2 pn libgnome-keyring0 ii libgtk-3-0 3.24.5-1 ii libgtk2.0-0 2.24.32-3 ii libgtkmm-2.4-1v5 1:2.24.5-4 pn libgtkmm-3.0-1v5 ii libmariadbclient18 [libmariadbclient18] 1:10.3.12-2 pn libmysqlcppconn7v5 ii libodbc1 2.3.6-0.1 ii libpango-1.0-0 1.42.4-6 ii libpangocairo-1.0-0 1.42.4-6 ii libpangomm-1.4-1v5 2.42.0-2 ii libpcre3 2:8.39-11 ii libpcrecpp0v52:8.39-11 ii libpython2.7 2.7.16~rc1-1 ii libsigc++-2.0-0v52.10.1-2 ii libstdc++6 8.2.0-21 pn libtinyxml2.6.2v5 ii libuuid1 2.33.1-0.1 pn libvsqlitepp3v5 ii libx11-6 2:1.6.7-1 ii libxml2 2.9.4+dfsg1-7+b3 ii libzip4 1.5.1-3 pn mysql-workbench-data ii python 2.7.15-4 pn python-mysql.connector ii python-paramiko 2.4.2-0.1 pn python-pexpect pn python-pyodbc pn python-pysqlite2 ii python2.72.7.16~rc1-1 Versions of packages mysql-workbench recommends: ii default-mysql-client1.0.5 ii mariadb-client-10.3 [virtual-mysql-client] 1:10.3.12-2 pn mysql-utilities ii ttf-bitstream-vera 1.10-8 Versions of packages mysql-workbench suggests: ii gnome-keyring 3.28.2-2
Bug#916587: AppArmor breaks virtio-gpu + virgl
I got the virto-gpu + Virgl configuration to work with the configuration file I posted. When I edited the file I fumbled a bit so I suspect what happened is that at some point I broke the AppArmor state in some subtle way. Then it all got fixed a bit later when I rebooted. So the important thing is: the file I posted works! -- Francois Gouget http://fgouget.free.fr/ question = ( to ) ? be : ! be; -- Wm. Shakespeare
Bug#916587: AppArmor breaks virtio-gpu + virgl
Thanks for posting this to the Debian bug list. It did indeed make
finding it easier!
Unfortunately I'm still getting the same error after modifying
/etc/apparmor.d/libvirt/TEMPLATE.qemu. Maybe I missed something.
Here's my file:
-
#include
profile LIBVIRT_TEMPLATE flags=(attach_disconnected) {
#include
/dev/dri/ r,
/dev/dri/renderD128 rw,
/etc/drirc r,
/{etc,usr/share}/glvnd/egl_vendor.d/ r,
/{etc,usr/share}/glvnd/egl_vendor.d/*.json r,
/sys/devices/pci[0-9]*/**/{device,subsystem_device,subsystem_vendor,uevent,vendor}
r,
/usr/lib/x86_64-linux-gnu/dri/*_dri.so m,
}
-
The errors are the same you were getting:
2019-01-10T00:01:34.834520Z qemu-system-x86_64: egl: no drm render node
available
2019-01-10T00:01:34.834548Z qemu-system-x86_64: Failed to initialize EGL render
node for SPICE GL
And kern.log has these audit entries:
Jan 10 01:01:34 amboise kernel: [225665.603042] audit: type=1400
audit(1547078494.295:809): apparmor="STATUS" operation="profile_load"
profile="unconfined" name="libvirt-c1cd8951-9ae3-4a76-a364-69f648d51447"
pid=32064 comm="apparmor_parser"
Jan 10 01:01:34 amboise kernel: [225665.728974] audit: type=1400
audit(1547078494.423:810): apparmor="STATUS" operation="profile_replace"
profile="unconfined" name="libvirt-c1cd8951-9ae3-4a76-a364-69f648d51447"
pid=32067 comm="apparmor_parser"
Jan 10 01:01:34 amboise kernel: [225665.868380] audit: type=1400
audit(1547078494.563:811): apparmor="STATUS" operation="profile_replace"
profile="unconfined" name="libvirt-c1cd8951-9ae3-4a76-a364-69f648d51447"
pid=32070 comm="apparmor_parser"
Jan 10 01:01:34 amboise kernel: [225665.977689] audit: type=1400
audit(1547078494.671:812): apparmor="STATUS" operation="profile_replace"
info="same as current profile, skipping" profile="unconfined"
name="libvirt-c1cd8951-9ae3-4a76-a364-69f648d51447" pid=32073
comm="apparmor_parser"
Jan 10 01:01:34 amboise kernel: [225666.077274] audit: type=1400
audit(1547078494.771:813): apparmor="STATUS" operation="profile_replace"
profile="unconfined" name="libvirt-c1cd8951-9ae3-4a76-a364-69f648d51447"
pid=32112 comm="apparmor_parser"
Jan 10 01:01:35 amboise kernel: [225666.357611] audit: type=1400
audit(1547078495.051:814): apparmor="STATUS" operation="profile_remove"
profile="unconfined" name="libvirt-c1cd8951-9ae3-4a76-a364-69f648d51447"
pid=32123 comm="apparmor_parser"
--
Francois Gouget http://fgouget.free.fr/
Stolen from an Internet user:
"f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"
Bug#904960: libvirglrenderer0: some documentation
It looks like the merge with bug 813658 failed. Since that bug is closed this one is unblocked and should maybe even be closed. -- Francois Gouget http://fgouget.free.fr/ In theory, theory and practice are the same, but in practice they're different.
Bug#910650: Acknowledgement (binutils-mingw-w64-i686: i686-w64-mingw32-windres fails to compile Wine's resources)
Sorry, the package links are missing an extra 'mingw-': http://fgouget.free.fr/tmp/binutils-mingw-w64/binutils-mingw-w64_2.28-5+7.4+w1_all.deb http://fgouget.free.fr/tmp/binutils-mingw-w64/binutils-mingw-w64_7.4+w1_amd64.buildinfo http://fgouget.free.fr/tmp/binutils-mingw-w64/binutils-mingw-w64_7.4+w1_amd64.changes http://fgouget.free.fr/tmp/binutils-mingw-w64/binutils-mingw-w64_7.4+w1.dsc http://fgouget.free.fr/tmp/binutils-mingw-w64/binutils-mingw-w64_7.4+w1.tar.xz http://fgouget.free.fr/tmp/binutils-mingw-w64/binutils-mingw-w64-i686_2.28-5+7.4+w1_amd64.deb http://fgouget.free.fr/tmp/binutils-mingw-w64/binutils-mingw-w64-i686-dbgsym_2.28-5+7.4+w1_amd64.deb http://fgouget.free.fr/tmp/binutils-mingw-w64/binutils-mingw-w64-x86-64_2.28-5+7.4+w1_amd64.deb http://fgouget.free.fr/tmp/binutils-mingw-w64/binutils-mingw-w64-x86-64-dbgsym_2.28-5+7.4+w1_amd64.deb -- Francois Gouget http://fgouget.free.fr/ Dieu dit: "M-x Lumière". Et la lumière fut.
Bug#910650: binutils-mingw-w64-i686: i686-w64-mingw32-windres fails to compile Wine's resources
Package: binutils-mingw-w64-i686 Version: 2.28-5+7.4+b4 Severity: normal Tags: patch Dear Maintainer, On 2018-10-01 a patch was applied to Wine to test custom dialog control data: https://source.winehq.org/git/wine.git/commit/606b0272776ec2a4e6146aa29a993fc88e98214b Unfortunately i686-w64-mingw32-windres fails to compile the new resource file: ../../.././../wine-native/tools/winegcc/winegcc -o user32_test.exe -B../../.././../wine-native/tools/winebuild \ --sysroot=../../.. -b i686-w64-mingw32 -fasynchronous-unwind-tables broadcast.o class.o \ clipboard.o combo.o cursoricon.o dce.o dde.o dialog.o edit.o generated.o input.o listbox.o menu.o \ monitor.o msg.o resource.o scroll.o static.o sysparams.o text.o uitools.o win.o winstation.o \ wsprintf.o resource.res testlist.o ../../../dlls/user32/libuser32.a ../../../dlls/gdi32/libgdi32.a \ ../../../dlls/advapi32/libadvapi32.a /usr/bin/i686-w64-mingw32-windres: dialog control data: not enough binary data This is caused by a binutils bug which was fixed by Dmitry Timoshkov: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=6bb21700abb61cdb62a3d9fdf417971d528d5a37 The good news is that this is fixed in Debian Testingi. But since Debian 9 is still the Debian release intended for mainstream use (and also the release used by Wine's TestBot) fixing this in Debian Stable would be really useful to Wine developers. So I propose the attatched patch (of course the changelog entry should be adjusted as approriate). You can also find the patched package source and binaries there: http://fgouget.free.fr/tmp/binutils-w64/binutils-mingw-w64_2.28-5+7.4+w1_all.deb http://fgouget.free.fr/tmp/binutils-w64/binutils-mingw-w64_7.4+w1_amd64.buildinfo http://fgouget.free.fr/tmp/binutils-w64/binutils-mingw-w64_7.4+w1_amd64.changes http://fgouget.free.fr/tmp/binutils-w64/binutils-mingw-w64_7.4+w1.dsc http://fgouget.free.fr/tmp/binutils-w64/binutils-mingw-w64_7.4+w1.tar.xz http://fgouget.free.fr/tmp/binutils-w64/binutils-mingw-w64-i686_2.28-5+7.4+w1_amd64.deb http://fgouget.free.fr/tmp/binutils-w64/binutils-mingw-w64-i686-dbgsym_2.28-5+7.4+w1_amd64.deb http://fgouget.free.fr/tmp/binutils-w64/binutils-mingw-w64-x86-64_2.28-5+7.4+w1_amd64.deb http://fgouget.free.fr/tmp/binutils-w64/binutils-mingw-w64-x86-64-dbgsym_2.28-5+7.4+w1_amd64.deb -- System Information: Debian Release: 9.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores) 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) Versions of packages binutils-mingw-w64-i686 depends on: ii binutils 2.28-5 ii libc6 2.24-11+deb9u3 ii zlib1g1:1.2.8.dfsg-5 binutils-mingw-w64-i686 recommends no packages. binutils-mingw-w64-i686 suggests no packages. -- no debconf information diff -ur binutils-mingw-w64-7.4/debian/changelog binutils-mingw-w64-7.4+w1/debian/changelog --- binutils-mingw-w64-7.4/debian/changelog 2017-01-02 20:06:20.0 +0100 +++ binutils-mingw-w64-7.4+w1/debian/changelog 2018-10-04 12:00:00.0 +0200 @@ -1,3 +1,9 @@ +binutils-mingw-w64 (7.4+w1) unstable; urgency=medium + + * Patched for Wine. + + -- Francois Goguet Thu, 04 Oct 2018 12:00:00 +0200 + binutils-mingw-w64 (7.4) unstable; urgency=medium * Add missing build dependencies on rdfind and symlinks. diff -ur binutils-mingw-w64-7.4/debian/patches/series binutils-mingw-w64-7.4+w1/debian/patches/series --- binutils-mingw-w64-7.4/debian/patches/series2016-09-06 13:18:43.0 +0200 +++ binutils-mingw-w64-7.4+w1/debian/patches/series 2017-01-02 20:06:20.0 +0100 @@ -2,3 +2,6 @@ specify-timestamp.patch dont-run-objcopy.patch default-secure-pe-flags.patch + +# Patches for Wine +wine-fix-optional-dialog-control-data.patch --- /dev/null 2018-09-25 02:08:19.254691583 +0200 +++ binutils-mingw-w64-7.4+w1/debian/patches/wine-fix-optional-dialog-control-data.patch 2017-01-02 20:06:20.0 +0100 @@ -0,0 +1,92 @@ +From 6bb21700abb61cdb62a3d9fdf417971d528d5a37 Mon Sep 17 00:00:00 2001 +From: Dmitry Timoshkov +Date: Wed, 18 Jan 2017 11:40:06 + +Subject: [PATCH] Stop the (optional) dialong control data from being aligned + when parsing/writing windows resource files. + +binutils* resbin.c: Optional dialog control data immediately follow + the control description without alignment. + * testsuite/binutils-all/windres/controldata.rc: New test. + source. + * testsuite/binutils-all/windres/controldata.rsd: New test. +--- + binutils/resbin.c | 7 ++- + .../binutils-all/windres/controldata.rc| 6 ++ + .../binutils-all/windres/controldata.rsd | 18 ++ + 4 files changed, 34 insertions(+), 5 deletions(-) + create mode 100644
Bug#783485: hplip: hp-levels, hp-info don't report the PSC-2175 color cartridge levels
Brian Potkin asked: > Is this still an issue with the present unstable/testing distribution? This bug is still present and very much an issue in hplip 3.17.10+repack. > Has a cartridge fault been ruled out? I have changed the ink cartridges since I reported the bug 3 years ago and yet the issue is still present. I'm using original / genuine / whatever-you-want-to-call-them HP cartridges too. I don't know how to rule out a cartridge fault otherwise. -- Francois Gouget http://fgouget.free.fr/ Dieu dit: "M-x Lumi\xC3\xA8re". Et la lumi\xC3\xA8re fut.
Bug#812228: python-pil: ambiguous package name 'python-pil' in maintainer scripts
Joe Crayne wrote: > What if $DPKG_MAINTSCRIPT_ARCH is empty? Can it actually be empty? When would it be empty? 'man dpkg' does not say anything about this being possible: $ man dpkg [...] DPKG_MAINTSCRIPT_ARCH Defined by dpkg on the maintainer script environment to the architecture the package got built for (since dpkg 1.15.4). [...] dpkg 1.15.4 was released in 2009. -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm
Bug#898970: rear should be Archiecture: all
Package: rear Version: 2.3+dfsg-1 Severity: normal Dear Maintainer, I compared the files of the amd64, i386 and ppc64el binary packages and they are all strictly identical. Thus the rear package is architecture independent and should be marked as such. That means: * Setting Architecture: all * Removing the Multi-Arch tag which becomes irrelevant. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Foreign Architectures: amd64 Kernel: Linux 4.16.0-1-686-pae (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages rear depends on: ii attr 1:2.4.47-2+b2 ii bc 1.07.1-2+b1 ii binutils 2.30-15 ii dosfstools 4.1-1 ii e2fsprogs1.44.1-2 ii ethtool 1:4.15-1 ii fdisk2.32-0.1 ii gawk 1:4.1.4+dfsg-1+b1 ii iproute2 4.16.0-2 ii iputils-ping 3:20161105-1 ii isolinux 3:6.03+dfsg1-2 ii lsb-release 9.20170808 ii openssl 1.1.0h-2 ii parted 3.2-21 ii syslinux 3:6.03+dfsg1-2 ii syslinux-common 3:6.03+dfsg1-2 ii util-linux 2.32-0.1 ii xorriso 1.4.8-3 Versions of packages rear recommends: ii extlinux 3:6.03+dfsg1-2 ii nfs-common [nfs-client] 1:1.3.4-2.2 ii rpcbind [portmap]0.2.3-0.6 rear suggests no packages. -- Configuration Files: /etc/rear/local.conf [Errno 13] Permission non accordée: '/etc/rear/local.conf' -- no debconf information
Bug#898957: libquazip5-1 is marked Multi-Arch: same but is not coinstallable
Package: libquazip5-1 Version: 0.7.3-7 Severity: normal Dear Maintainer, Trying to install the amd64 and i386 versions of this package results in the following error: # apt-get install libquazip5-1:i386 libquazip5-1:amd64 [...] Unpacking libquazip5-1:amd64 (0.7.3-7) ... dpkg: dependency problems prevent configuration of libquazip5-1:amd64: libquazip5-1:i386 (0.7.3-7) breaks libquazip-qt5-1 and is installed. libquazip5-1:amd64 (0.7.3-7) provides libquazip-qt5-1. libquazip5-1:i386 (0.7.3-7) breaks libquazip1-qt5 and is installed. libquazip5-1:amd64 (0.7.3-7) provides libquazip1-qt5. dpkg: error processing package libquazip5-1:amd64 (--configure): dependency problems - leaving unconfigured So the source of the issue seems to be that libquazip5-1: * Provides the libquazip-qt5-1 and libquazip1-qt5 virtual packages * Breaks + Replaces the libquazip-qt5-1 and libquazip1-qt5 virtual packages Apt seems to consider that this means libquazip5-1:amd64 breaks libquazip5-1:i386 through the libquazip-qt5-1 and libquazip1-qt5 virtual packages which prevents them from being coinstalled. One strange thing is that, if I understand 7.6.1 of the Debian Policy Manual correctly, Breaks + Replaces is not supposed to be used on virtual packages: http://www.chiark.greenend.org.uk/doc/debian-policy/policy.html/ch-relationships.html#s7.6.1 | For this usage of Replaces, virtual packages (see Virtual packages - Provides, | Section 7.5) are not considered when looking at a Replaces field. The packages | declared as being replaced must be mentioned by their real names. Maybe that's why Apt is confused in this multi-arch configuration. Note that, based on 7.6.2, the usual pattern for virtual packages would be Provides + Conflicts + Replaces: | In this situation, the package declared as being replaced can be a virtual | package, so for example, all mail transport agents (MTAs) would have the | following fields in their control files: | | Provides: mail-transport-agent | Conflicts: mail-transport-agent | Replaces: mail-transport-agent | | ensuring that only one MTA can be unpacked at any one time Seems like something to try to see if it fixes the issue. But libquazip-qt5-1 and libquazip1-qt5 may well have been real packages at some point. However currently their only existence is through the Provides of libquazip5-1. Still if the goal it to state that libquazip5-1 breaks these old packages (to ensure clean upgrades), then a Breaks + version number would probably be the right thing to do (see 7.5 of the policy): http://www.chiark.greenend.org.uk/doc/debian-policy/policy.html/ch-relationships.html#s-virtual | If a relationship field has a version number attached, only real packages will | be considered to see whether the relationship is satisfied (or the prohibition | violated, for a conflict or breakage). In other words, if a version number is | specified, this is a request to ignore all Provides for that package name and | consider only real packages. The package manager will assume that a package | providing that virtual package is not of the "right" version. A Provides field | may not contain version numbers, and the version number of the concrete package | which provides a particular virtual package will not be considered when | considering a dependency on or conflict with the virtual package name. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Foreign Architectures: amd64 Kernel: Linux 4.16.0-1-686-pae (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libquazip5-1 depends on: ii libc6 2.27-3 ii libgcc1 1:8.1.0-1 ii libqt5core5a 5.10.1+dfsg-6 ii libstdc++68.1.0-1 ii zlib1g1:1.2.11.dfsg-1 libquazip5-1 recommends no packages. Versions of packages libquazip5-1 suggests: pn libquazip-doc -- no debconf information
Bug#898956: libmateweather1 is marked Multi-Arch: same but is not coinstallable
Package: libmateweather1 Version: 1.20.0-1 Severity: normal Dear Maintainer, Trying to install the amd64 and i386 versions of this package results in the following error: # apt-get install libmateweather1:i386 libmateweather1:amd64 [...] dpkg: dependency problems prevent configuration of libmateweather1:amd64: libmateweather1:i386 (1.20.0-1) breaks libmateweather and is installed. libmateweather1:amd64 (1.20.0-1) provides libmateweather. dpkg: error processing package libmateweather1:amd64 (--configure): dependency problems - leaving unconfigured So the source of the issue seems to be that libquazip5-1: * Provides the libmateweather virtual package * Breaks AND Conflicts with the libmateweather virtual package! * Replaces the libmateweather virtual package Apt seems to consider that this means libmateweather1:amd64 breaks libmateweather1:i386 through the libmateweather virtual package which prevents them from being coinstalled. One strange thing is that, if I understand 7.6.1 of the Debian Policy Manual correctly, Breaks + Replaces is not supposed to be used on virtual packages: http://www.chiark.greenend.org.uk/doc/debian-policy/policy.html/ch-relationships.html#s7.6.1 | For this usage of Replaces, virtual packages (see Virtual packages - Provides, | Section 7.5) are not considered when looking at a Replaces field. The packages | declared as being replaced must be mentioned by their real names. Maybe that's why Apt is confused in this multi-arch configuration. Note that, based on 7.6.2, the usual pattern for virtual packages would be Provides + Conflicts + Replaces: | In this situation, the package declared as being replaced can be a virtual | package, so for example, all mail transport agents (MTAs) would have the | following fields in their control files: | | Provides: mail-transport-agent | Conflicts: mail-transport-agent | Replaces: mail-transport-agent | | ensuring that only one MTA can be unpacked at any one time Finally libmateweather may well have been a real package at some point. However currently its only existence is through the Provides of libmateweather1. Still if the goal it to state that libmateweather1 breaks this old package (to ensure clean upgrades), then a Breaks + version number would probably be the right thing to do (see 7.5 of the policy): http://www.chiark.greenend.org.uk/doc/debian-policy/policy.html/ch-relationships.html#s-virtual | If a relationship field has a version number attached, only real packages will | be considered to see whether the relationship is satisfied (or the prohibition | violated, for a conflict or breakage). In other words, if a version number is | specified, this is a request to ignore all Provides for that package name and | consider only real packages. The package manager will assume that a package | providing that virtual package is not of the "right" version. A Provides field | may not contain version numbers, and the version number of the concrete package | which provides a particular virtual package will not be considered when | considering a dependency on or conflict with the virtual package name. In any case it does not seem like libmateweather1 should combine Breaks and Conflicts. Note that libmate-panel-applet-4-1 has a similar issue with libmatepanelapplet. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Foreign Architectures: amd64 Kernel: Linux 4.16.0-1-686-pae (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libmateweather1 depends on: ii libatk1.0-02.28.1-1 ii libc6 2.27-3 ii libcairo-gobject2 1.15.10-3 ii libcairo2 1.15.10-3 ii libgdk-pixbuf2.0-0 2.36.11-2 ii libglib2.0-0 2.56.1-2 ii libgtk-3-0 3.22.29-3 ii libmateweather-common 1.20.0-1 ii libpango-1.0-0 1.42.0-1 ii libpangocairo-1.0-01.42.0-1 ii libsoup2.4-1 2.62.1-1 ii libxml22.9.4+dfsg1-6.1 libmateweather1 recommends no packages. libmateweather1 suggests no packages. -- no debconf information
Bug#898820: libicu-dev is not Multi-Arch compatible
Package: libicu-dev Version: 57.1-9 Severity: normal Dear Maintainer, libicu-dev is not multi-arch aware, causing the i386 version to conflict with the amd64 one which makes it impossible to install both. As a result the /usr/lib/i386-linux-gnu/libicu*.so symbolic links are missing so that developping 32 bit applications using this library is impossible on a 64 bit system. In turn this impacts Wine development as it needs to support both 32 and 64 bit Windows applications and needs libxml2-dev for that. libxml2-dev itself is multi-arch same but it depends on libicu-dev and thus it's impossible to install both versions of libxml2-dev at the same time. The lack of multi-arch support in libicu-dev also breaks multi-arch support in the following packages: fis-gtm-6.3-003a libboost-regex1.62-dev libcdr-dev libe-book-dev libharfbuzz-dev libical-dev libmspub-dev libvisio-dev libxslt1-dev. So the impact is quite wide ranging. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libicu-dev depends on: ii icu-devtools 57.1-9 ii libc6-dev [libc-dev] 2.27-3 ii libicu57 57.1-9 ii libstdc++-5-dev [libstdc++-dev] 5.4.1-4 ii libstdc++-6-dev [libstdc++-dev] 6.4.0-12 ii libstdc++-7-dev [libstdc++-dev] 7.3.0-17 libicu-dev recommends no packages. Versions of packages libicu-dev suggests: pn icu-doc -- no debconf information
Bug#898055: ibverbs-providers is marked Multi-Arch: same but is not coinstallable
On Mon, 14 May 2018, Jason Gunthorpe wrote: [...] > I think the correct solution is this text: > > If a relationship field has a version number attached, only real > packages will be considered to see whether the relationship is > satisfied (or the prohibition violated, for a conflict or > breakage). In other words, if a version number is specified, this is a > request to ignore all Provides for that package name and consider only > real packages. The package manager will assume that a package > providing that virtual package is not of the "right" version. A > Provides field may not contain version numbers, and the version number > of the concrete package which provides a particular virtual package > will not be considered when considering a dependency on or conflict > with the virtual package name.[52] Yes that works. I tested and I can coinstall version 18.0 of libibverbs1 + ibverbs-providers. So this is fixed. Thanks. -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.
Bug#898056: gir1.2-anjuta-3.0: Differing versions break multi-arch support
Package: gir1.2-anjuta-3.0 Version: 2:3.28.0-1+b1 Severity: normal Dear Maintainer, This concerns Debian Testing and Unstable: * For the amd64, arm64, armel, mips64el and s390x architectures only version 2:3.28.0-1+b1 is available. * For the armhf, i386, mips, mipsel and ppc64el architectures only version 2:3.28.0-1 is available. * But gir1.2-anjuta-3.0 says that it breaks any version that's different. For instance: Breaks: gir1.2-anjuta-3.0 (!= 2:3.28.0-1+b1) Thus, because the amd64 and i386 architectures (for instance) are not available in the same version, they are not coinstallable, thus breaking multi-arch support. Presumably at some point a new version will be available for all architectures, which will fix this. But this illustrates that: * Either the Breaks: statement should be revised. Maybe it should target releases older than a specific version for instance or could be removed. * Or one should not just rebuild the package for a subset of the architectures to avoid breaking multi-arch. Note that libanjuta-3-0 and libanjuta-dev suffer from the same issue. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores) 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) Versions of packages gir1.2-anjuta-3.0 depends on: pn gir1.2-gdl-3 ii gir1.2-glib-2.0 1.56.1-1 ii gir1.2-gtk-3.0 3.22.29-3 pn libanjuta-3-0 gir1.2-anjuta-3.0 recommends no packages. gir1.2-anjuta-3.0 suggests no packages. -- no debconf information
Bug#898054: growisofs: Please make Multi-Arch: foreign
Package: growisofs Version: 7.1-12 Severity: normal Dear Maintainer, brasero-cdrkit is Multi-Arch: same but depends on growisofs because it needs to run the tools growisofs provides. This is ok but can only work if growisofs is marked Multi-Arch: foreign. Fortunately since growisofs only provides tools that should be no issue. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores) 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) Versions of packages growisofs depends on: ii libc6 2.27-3 ii libgcc1 1:8-20180425-1 ii libstdc++6 8-20180425-1 growisofs recommends no packages. growisofs suggests no packages. -- no debconf information
Bug#898058: genisoimage: Please make Multi-Arch: foreign
Package: genisoimage Version: 9:1.1.11-3+b2 Severity: normal Dear Maintainer, brasero-cdrkit and libguestfs0 are Multi-Arch: same but depend on genisoimage because they need to run the tools it provides. This is ok but can only work if genisoimage is marked Multi-Arch: foreign. Fortunately since genisoimage only provides tools that should be no issue. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores) 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) Versions of packages genisoimage depends on: ii libbz2-1.0 1.0.6-8.1 ii libc6 2.27-3 ii libmagic1 1:5.32-2 ii zlib1g 1:1.2.8.dfsg-5 genisoimage recommends no packages. Versions of packages genisoimage suggests: pn cdrkit-doc pn wodim -- no debconf information
Bug#898055: ibverbs-providers is marked Multi-Arch: same but is not coinstallable
Package: ibverbs-providers Version: 17.1-2 Severity: normal Dear Maintainer, Trying to install the amd64 and i386 versions of this package results in the following error: # apt-get install ibverbs-providers:amd64 ibverbs-providers:i386 [...] Unpacking ibverbs-providers:i386 (17.1-1) ... Processing triggers for libc-bin (2.27-3) ... dpkg: dependency problems prevent configuration of ibverbs-providers:i386: ibverbs-providers:amd64 (17.1-1) breaks libcxgb3-1 and is installed. ibverbs-providers:i386 (17.1-1) provides libcxgb3-1. ibverbs-providers:amd64 (17.1-1) breaks libipathverbs1 and is installed. ibverbs-providers:i386 (17.1-1) provides libipathverbs1. ibverbs-providers:amd64 (17.1-1) breaks libmlx4-1 and is installed. ibverbs-providers:i386 (17.1-1) provides libmlx4-1. ibverbs-providers:amd64 (17.1-1) breaks libmlx5-1 and is installed. ibverbs-providers:i386 (17.1-1) provides libmlx5-1. ibverbs-providers:amd64 (17.1-1) breaks libmthca1 and is installed. ibverbs-providers:i386 (17.1-1) provides libmthca1. ibverbs-providers:amd64 (17.1-1) breaks libnes1 and is installed. ibverbs-providers:i386 (17.1-1) provides libnes1. dpkg: error processing package ibverbs-providers:i386 (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: ibverbs-providers:i386 E: Sub-process /usr/bin/dpkg returned an error code (1) So the source of the issue seems to be that ibverbs-providers: * Provides a bunch of virtual packages * Breaks + Replaces these virtual packages Apt seems to consider that this means ibverbs-providers:amd64 breaks ibverbs-providers:i386 through the virtual packages which prevents them from being coinstalled. One strange thing is that, if I understand 7.6.1 of the Debian Policy Manual correctly, Breaks + Replaces is not supposed to be used on virtual packages: http://www.chiark.greenend.org.uk/doc/debian-policy/policy.html/ch-relationships.html#s7.6.1 | For this usage of Replaces, virtual packages (see Virtual packages - Provides, | Section 7.5) are not considered when looking at a Replaces field. The packages | declared as being replaced must be mentioned by their real names. Maybe that's why Apt is confused in this multi-arch configuration. Note that, based on 7.6.2, the usual pattern for virtual packages would be Provides + Conflicts + Replaces: | In this situation, the package declared as being replaced can be a virtual | package, so for example, all mail transport agents (MTAs) would have the | following fields in their control files: | | Provides: mail-transport-agent | Conflicts: mail-transport-agent | Replaces: mail-transport-agent | | ensuring that only one MTA can be unpacked at any one time Seems like something to try to see if it fixes the issue. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores) 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) Versions of packages ibverbs-providers depends on: ii libc62.27-3 ii libibverbs1 17.1-2 ibverbs-providers recommends no packages. ibverbs-providers suggests no packages. -- no debconf information
Bug#898057: wodim: Please make Multi-Arch: foreign
Package: wodim Version: 9:1.1.11-3+b2 Severity: normal Dear Maintainer, brasero-cdrkit is Multi-Arch: same but depends on wodim because it needs to run the tools wodim provides. This is ok but can only work if wodim is marked Multi-Arch: foreign. Fortunately since wodim only provides tools that should be no issue. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores) 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) Versions of packages wodim depends on: ii libc62.27-3 ii libcap2 1:2.25-1.2 Versions of packages wodim recommends: pn genisoimage Versions of packages wodim suggests: pn cdrkit-doc -- no debconf information
Bug#898051: libruby2.5 is marked Multi-Arch: same but has a conflicting file
Package: libruby2.5 Version: 2.5.1-1 Severity: normal Dear Maintainer, Trying to install the amd64 and i386 versions of this package results in the following error: # apt-get install libruby2.5:amd64 libruby2.5:i386 [...] Unpacking libruby2.5:i386 (2.5.1-1) ... dpkg: error processing archive /var/cache/apt/archives/libruby2.5_2.5.1-1_i386.deb (--unpack): trying to overwrite shared '/usr/lib/ruby/gems/2.5.0/specifications/default/fiddle-1.0.0.gemspec', which is different from other instances of package libruby2.5:i386 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/libruby2.5_2.5.1-1_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) The other multi-arch same Ruby packages depend on this one too so it would be great to fix this issue. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores) 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) Versions of packages libruby2.5 depends on: ii libc6 2.27-3 ii libffi63.2.1-8 ii libgdbm-compat41.14.1-6 ii libgdbm5 1.14.1-6 ii libgmp10 2:6.1.2+dfsg-3 ii libncurses56.1-1 ii libreadline7 7.0-3 ii libssl1.1 1.1.0h-2 ii libtinfo5 6.1-1 ii libyaml-0-20.1.7-2 pn rake pn ruby-did-you-mean pn ruby-minitest pn ruby-net-telnet pn ruby-test-unit ii zlib1g 1:1.2.8.dfsg-5 libruby2.5 recommends no packages. libruby2.5 suggests no packages. -- no debconf information
Bug#898050: libitalccore is marked Multi-Arch: same but is not coinstallable
Package: libitalccore Version: 1:3.0.3+dfsg1-3 Severity: normal Dear Maintainer, Trying to install the amd64 and i386 versions of this package results in the following error: # apt-get install libitalccore:amd64 libitalccore:i386 [...] Setting up libqt5svg5:i386 (5.10.1-2) ... dpkg: dependency problems prevent configuration of libitalccore:i386: libitalccore:amd64 (1:3.0.3+dfsg1-3) breaks libitalc and is installed. libitalccore:i386 (1:3.0.3+dfsg1-3) provides libitalc. dpkg: error processing package libitalccore:i386 (--configure): dependency problems - leaving unconfigured Processing triggers for libc-bin (2.27-3) ... Errors were encountered while processing: libitalccore:i386 So the source of the issue seems to be that libitalccore: * Provides the libitalc virtual package * Breaks + Replaces the libitalc virtual package Apt seems to consider that this means libitalccore:amd64 breaks libitalccore:i386 through the libitalc virtual package which prevents them from being coinstalled. One strange thing is that, if I understand 7.6.1 of the Debian Policy Manual correctly, Breaks + Replaces is not supposed to be used on virtual packages: http://www.chiark.greenend.org.uk/doc/debian-policy/policy.html/ch-relationships.html#s7.6.1 | For this usage of Replaces, virtual packages (see Virtual packages - Provides, | Section 7.5) are not considered when looking at a Replaces field. The packages | declared as being replaced must be mentioned by their real names. Maybe that's why Apt is confused in this multi-arch configuration. Note that, based on 7.6.2, the usual pattern for virtual packages would be Provides + Conflicts + Replaces: | In this situation, the package declared as being replaced can be a virtual | package, so for example, all mail transport agents (MTAs) would have the | following fields in their control files: | | Provides: mail-transport-agent | Conflicts: mail-transport-agent | Replaces: mail-transport-agent | | ensuring that only one MTA can be unpacked at any one time Seems like something to try to see if it fixes the issue. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores) 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) Versions of packages libitalccore depends on: ii dpkg 1.19.0.5 ii libc62.27-3 ii libgcc1 1:8-20180425-1 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libpng16-16 1.6.34-1 ii libqt5core5a 5.10.1+dfsg-5 ii libqt5gui5 5.10.1+dfsg-5 ii libqt5network5 5.10.1+dfsg-5 ii libqt5widgets5 5.10.1+dfsg-5 ii libqt5xml5 5.10.1+dfsg-5 ii libssl1.11.1.0h-2 ii libstdc++6 8-20180425-1 ii zlib1g 1:1.2.8.dfsg-5 libitalccore recommends no packages. libitalccore suggests no packages. -- no debconf information
Bug#898053: libbabl-dev is marked Multi-Arch: same but is not coinstallable
Package: libbabl-dev Version: 0.1.46-2 Severity: normal Dear Maintainer, Trying to install the amd64 and i386 versions of this package results in the following error: # apt-get install libbabl-dev:amd64 libbabl-dev:i386 [...] Unpacking libbabl-dev:i386 (0.1.46-2) ... dpkg: dependency problems prevent configuration of libbabl-dev:i386: libbabl-dev:amd64 (0.1.46-2) breaks libbabl-0.0-0-dev and is installed. libbabl-dev:i386 (0.1.46-2) provides libbabl-0.0-0-dev. dpkg: error processing package libbabl-dev:i386 (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: libbabl-dev:i386 E: Sub-process /usr/bin/dpkg returned an error code (1) So the source of the issue seems to be that libbabl-dev: * Provides the libbabl-0.0-0-dev virtual package * Breaks + Replaces the libbabl-0.0-0-dev virtual package Apt seems to consider that this means libbabl-dev:amd64 breaks libbabl-dev:i386 through the libbabl-0.0-0-dev virtual package which prevents them from being coinstalled. One strange thing is that, if I understand 7.6.1 of the Debian Policy Manual correctly, Breaks + Replaces is not supposed to be used on virtual packages: http://www.chiark.greenend.org.uk/doc/debian-policy/policy.html/ch-relationships.html#s7.6.1 | For this usage of Replaces, virtual packages (see Virtual packages - Provides, | Section 7.5) are not considered when looking at a Replaces field. The packages | declared as being replaced must be mentioned by their real names. Maybe that's why Apt is confused in this multi-arch configuration. Note that, based on 7.6.2, the usual pattern for virtual packages would be Provides + Conflicts + Replaces: | In this situation, the package declared as being replaced can be a virtual | package, so for example, all mail transport agents (MTAs) would have the | following fields in their control files: | | Provides: mail-transport-agent | Conflicts: mail-transport-agent | Replaces: mail-transport-agent | | ensuring that only one MTA can be unpacked at any one time Seems like something to try to see if it fixes the issue. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores) 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) Versions of packages libbabl-dev depends on: pn libbabl-0.1-0 libbabl-dev recommends no packages. libbabl-dev suggests no packages. -- no debconf information
Bug#898049: libdune-grid-dev: Differing versions break multi-arch support
Package: libdune-grid-dev Version: 2.6.0-1+b1 Severity: normal Dear Maintainer, This concerns Debian Testing and Unstable: * For the alpha, amd64, arm64, mips64el and ppc64el architectures only version 2.6.0-1+b1 is available. * For the armel, armhf, i386, mipsel and x32 architectures only version 2.6.0-1 is available. But libdune-grid-dev says that it breaks any version that's different. For instance: Breaks: libdune-grid-dev (!= 2.6.0-1+b1) Thus, because the amd64 and i386 architectures (for instance) are not available in the same version, they are not coinstallable, thus breaking multi-arch support. Presumably at some point a new version will be available for all architectures, which will fix this. But this illustrates that: * Either the Breaks: statement should be revised. Maybe it should target releases older than a specific version or could be removed. * Or one should not just rebuild this package for a subset of the architectures to avoid breaking multi-arch. Note that libdune-grid-glue-dev and libdune-pdelab-dev suffer from the same issue. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores) 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) Versions of packages libdune-grid-dev depends on: pn libalberta-dev pn libalberta4 ii libc6 2.27-3 pn libdune-common-2.6.0 pn libdune-common-dev pn libdune-geometry-2.6.0 pn libdune-geometry-dev pn libdune-uggrid-2.6.0 pn libdune-uggrid-dev ii libgcc1 1:8-20180425-1 ii libltdl72.4.6-2.1 ii libopenmpi3 3.0.1-9 ii libstdc++6 8-20180425-1 libdune-grid-dev recommends no packages. Versions of packages libdune-grid-dev suggests: pn libdune-grid-doc -- no debconf information
Bug#898052: libupnp6-dev is marked Multi-Arch: same but has a conflicting file
Package: libupnp6-dev Version: 1:1.6.24-4 Severity: normal Dear Maintainer, Trying to install the amd64 and i386 versions of this package results in the following error: # apt-get install libupnp6-dev:amd64 libupnp6-dev:i386 [...] Unpacking libupnp6-dev:i386 (1:1.6.24-4) ... dpkg: error processing archive /var/cache/apt/archives/libupnp6-dev_1%3a1.6.24-4_i386.deb (--unpack): trying to overwrite shared '/usr/include/upnp/upnpconfig.h', which is different from other instances of package libupnp6-dev:i386 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/libupnp6-dev_1%3a1.6.24-4_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores) 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) Versions of packages libupnp6-dev depends on: pn libupnp6 libupnp6-dev recommends no packages. Versions of packages libupnp6-dev suggests: pn libupnp6-doc -- no debconf information
Bug#898041: libseafile0 breaks package system in multiarch setting
Package: libseafile0 Version: 6.1.5-1 Severity: critical Justification: breaks unrelated software Dear Maintainer, libseafile0 is marked as Multi-Arch: same but its postinst and preinst scripts call pycompile and pyclean without specifying the package architecture. As a result if libseafile0 is installed for more than one architecture the package name is ambiguous, causing the postinst and prerm scripts fail. This then prevents any package from being installed or removed, thus breaking the packaging system permanently (hence the critical severity). The solution is to replace the following line in /var/lib/dpkg/info/libseafile0:*.postinst pycompile -p libseafile0 with pycompile -p libseafile0:$DPKG_MAINTSCRIPT_ARCH And the following lines in /var/lib/dpkg/info/libseafile0:*.prerm pyclean -p libseafile0 else dpkg -L libseafile0 | grep '\.py$' | while read file with pyclean -p libseafile0:$DPKG_MAINTSCRIPT_ARCH else dpkg -L libseafile0:$DPKG_MAINTSCRIPT_ARCH | grep '\.py$' | while read file Note that this bugs currently affects Debian Testing. See also bug #770625 which shows how this same bug was fixed in gir1.2-ibus-1.0. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores) 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 libseafile0:amd64 depends on: ii libc6 2.27-3 ii libglib2.0-0 2.56.1-2 ii libjansson4 2.11-1 ii libsearpc13.0.8-4 ii python2.7.15~rc1-1 libseafile0:amd64 recommends no packages. libseafile0:amd64 suggests no packages. -- no debconf information
Bug#897990: gscan2pdf assertion failed when completing a scan
On Sat, 5 May 2018, Jeff wrote: [...] > That is cairo crashing and taking Perl with it. This report looks > similar and suggests that the problem is connected to the image size: > > https://bugzilla.redhat.com/show_bug.cgi?id=1132667 > > Would you mind testing to see whether smaller images also have the same > problem? Yes. That's the bug. Scanning in color or grayscale at 300 dpi works. Scanning at 600 dpi triggers the crash, whether that's in grayscale or color (I guess it's all color in memory anyway). > This bug report suggests a solution. Would you mind trying it out? > > https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1520211/comments/5 Yep. That works. Here are some more tidbits: * The default shmmax value on my system is 268435456 (256GB). Increasing that to 536870912 (512GB) fixes the crash. * One can change the shmmax without rebooting with: echo 536870912 >/proc/sys/kernel/shmmax * To repeat the referenced bug reports, to make the setting permanent add the following line to /etc/sysctl.conf: kernel.shmmax = 536870912 * Setting shmmax to 536870911 (512GB - 1 byte) does not avoid the crash. * The reason scanimage allowed me to work around the bug before is because the default dpi sucks! * I can also reproduce the crash by using gimp to save the 600 dpi image to a png file and then loading that png file in gscan2pdf. So the issue is indeed not related to the scanner interface. The 600 dpi PNG file resolution is 5098x7012. * But scanning with a 1200 dpi resolution directly in gscan2pdf works fine. This may indicate that it's not necessary to keep increasing shmmax to work on higher and higher resolution images. * Interestingly, even with shmmax set to 512GB gscan2pdf cannot load a 1200 dpi png file (10196x14024): ERROR - Exception 445: cache resources exhausted `/home/fgouget/Documents/c1200.png' @ error/cache.c/OpenPixelCache/4076 ERROR - /home/fgouget/Documents/c1200.png is not a recognised image type So this indicates a separate (memory?) issue in the PNG code. * I upgraded my system on 2018/04/14 and scanning worked on the 15th. I did another upgrade on the 15th (before or after scanning) and again on the 20th and I think the 2018/05/05 is the next time I scanned. That's when I noticed things were broken. So something changed in that interval and broke things. Obviously I did not manually changed shmmax. -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ There are 10 types of people in the world... those who understand binary and those who don't.
Bug#897352: Acknowledgement (libosmo-ranap-dev claims to be Multi-Arch: same but is not)
This is a duplicate of bug 897345. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897345 Sorry. There was an email issue on my end that caused the report to be sent twice. -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ Indifference will certainly be the downfall of mankind, but who cares?
Bug#897354: Acknowledgement (libvisual-0.4-dev claims to be Multi-Arch: same but is not)
This is a duplicate of bug 897344. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897344 Sorry. There was an email issue on my end that caused the report to be sent twice. -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ Dieu dit: "M-x Lumi\xC3\xA8re". Et la lumi\xC3\xA8re fut.
Bug#897351: Acknowledgement (libmstch-dev claims to be Multi-Arch: same but is not)
This is a duplicate of bug 897342. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897342 Sorry. There was an email issue on my end that caused the report to be sent twice. -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ A black hole is just God dividing by zero.
Bug#897357: Acknowledgement (libpfm4-dev claims to be Multi-Arch: same but is not)
This is a duplicate of bug 897343. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897343 Sorry. There was an email issue on my end that caused the report to be sent twice. -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ Dieu dit: "M-x Lumi\xC3\xA8re". Et la lumi\xC3\xA8re fut.
Bug#897356: Acknowledgement (libjson-glib-dev claims to be Multi-Arch: same but is not)
This is a duplicate of bug 897341. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897341 Sorry. There was an email issue on my end that caused the report to be sent twice. -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ Un western sans indien c'est comme une police sans serif. -- John Wayne
Bug#897353: Acknowledgement (libcidr-dev claims to be Multi-Arch: same but is not)
This is a duplicate of bug 897340. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897340 Sorry. There was an email issue on my end that causes the report to be sent twice. -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm
Bug#897355: Acknowledgement (libtorch-th-dev claims to be Multi-Arch: same but is not)
This is a duplicate of bug 897339. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897339 Sorry. There was an email issue on my end that causes the report to be sent twice. -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ If you think the whole world revolves around you, quit staring at the GPS display while driving.
Bug#882383: Bug#897328: libgeocode-glib-dev claims to be Multi-Arch: same but is not
On Tue, 1 May 2018, Simon McVittie wrote: > Control: tags 897328 + patch > Control: tags 897341 + patch > > On Tue, 01 May 2018 at 07:34:26 -0400, Francois Gouget wrote: > > Trying to install the amd64 and i386 versions of this > > package results in the following error: > ... > > trying to overwrite shared > > '/usr/include/geocode-glib-1.0/geocode-glib/geocode-enum-types.h', which is > > different from other instances of package libgeocode-glib-dev:i386 > > Are you doing a mass-bug-filing for this? Sort of. I'm checking which packages have broken multi-arch support. > This looks like a different symptom of the same root cause as > <https://bugs.debian.org/882446> and <https://bugs.debian.org/882383>, > and would probably be fixed by the same patches. Right. I missed that the patches for these bugs touch the same headers that cause trouble for multi-arch. So my libjson-glib-dev and libgeocode-glib-dev reports are indeed duplicates. -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ Hiroshima '45 - Czernobyl '86 - Windows '95
Bug#897363: gir1.2-ibus-1.0:amd64: Unqualified gir1.2-ibus-1.0 package name in prerm
Package: gir1.2-ibus-1.0 Version: 1.5.18-1 Severity: normal Dear Maintainer, The prerm script contains the following: else dpkg -L gir1.2-ibus-1.0 | perl -ne 's,/([^/]*)\.py$,/__pycache__/\1.*, or next; unlink $_ or die $! foreach glob($_)' Should this line be run when more than one architecture of gir1.2-ibus-1.0 is installed, it would fail because the package name lacks the architecture specifier. This would then break the whole packaging system. Fortunately I expect that this line cannot be run because gir1.2-ibus-1.0 depends on python3 which depends on python3-minimal which provides /usr/bin/py3clean. This is also why this bug is not critical. So one option would be to remove this line and the whole py3clean check. If not, then the dpkg call should be changed to: dpkg -L gir1.2-ibus-1.0:$DPKG_MAINTSCRIPT_ARCH | perl -ne 's,/([^/]*)\.py$,/__pycache__/\1.*, or next; unlink $_ or die $! foreach glob($_)' -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores) 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 gir1.2-ibus-1.0:amd64 depends on: ii gir1.2-glib-2.0 1.56.1-1 ii libibus-1.0-51.5.18-1 ii python3 3.6.4-1 gir1.2-ibus-1.0:amd64 recommends no packages. gir1.2-ibus-1.0:amd64 suggests no packages. -- no debconf information
Bug#897358: python-pjproject breaks package system in multiarch setting
Package: python-pjproject Version: 2.7.2~dfsg-1 Severity: critical Justification: breaks unrelated software Dear Maintainer, python-pjproject is marked as Multi-Arch: same but its postinst and preinst scripts call pycompile and pyclean without specifying the package architecture. As a result if python-pjproject is installed for more than one architecture the package name is ambiguous, causing the postinst and prerm scripts fail. This then prevents any package from being installed or removed, thus breaking the packaging system permanently. The solution is to replace the following line in /var/lib/dpkg/info/python-pjproject:*.postinst pycompile -p python-pjproject with pycompile -p python-pjproject:$DPKG_MAINTSCRIPT_ARCH And the following line in /var/lib/dpkg/info/python-pjproject:*.prerm pyclean -p python-pjproject else dpkg -L python-pjproject | grep '\.py$' | while read file with pyclean -p python-pjproject:$DPKG_MAINTSCRIPT_ARCH else dpkg -L python-pjproject:$DPKG_MAINTSCRIPT_ARCH | grep '\.py$' | while read file See also bug #770625 which shows how this same bug was fixed in gir1.2-ibus-1.0. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores) 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 python-pjproject:amd64 depends on: ii libc6 2.27-3 ii libpj2 2.7.2~dfsg-1 ii libpjsip2 2.7.2~dfsg-1 ii libpjsua2 2.7.2~dfsg-1 python-pjproject:amd64 recommends no packages. python-pjproject:amd64 suggests no packages. -- no debconf information
Bug#897359: libmarco-private1 is marked Multi-Arch: same but is not coinstallable
Package: libmarco-private1 Version: 1.20.1-1 Severity: normal Dear Maintainer, Trying to install the amd64 and i386 versions of this package results in the following error: # apt-get install libmarco-private1:amd64 libmarco-private1:i386 [...] Unpacking libmarco-private1:i386 (1.20.1-1) ... dpkg: dependency problems prevent configuration of libmarco-private1:i386: libmarco-private1:amd64 (1.20.1-1) breaks libmarco and is installed. libmarco-private1:i386 (1.20.1-1) provides libmarco. dpkg: error processing package libmarco-private1:i386 (--configure): dependency problems - leaving unconfigured Processing triggers for libc-bin (2.27-3) ... Errors were encountered while processing: libmarco-private1:i386 E: Sub-process /usr/bin/dpkg returned an error code (1) So the source of the issue seems to be that libmarco-private1: * Provides the libmarco virtual package * Breaks + Replaces the libmarco virtual package Apt seems to consider that this means libmarco-private1:amd64 breaks libmarco-private1:i386 through the libmarco virtual package which prevents them from being coinstalled. One strange thing is that, if I understand 7.6.1 of the Debian Policy Manual correctly, Breaks + Replaces is not supposed to be used on virtual packages: http://www.chiark.greenend.org.uk/doc/debian-policy/policy.html/ch-relationships.html#s7.6.1 | For this usage of Replaces, virtual packages (see Virtual packages - Provides, | Section 7.5) are not considered when looking at a Replaces field. The packages | declared as being replaced must be mentioned by their real names. Maybe that's why Apt is confused in this multi-arch configuration. Note that, based on 7.6.2, the usual pattern would be to Provides + Conflicts + Replaces on a virtual package: | In this situation, the package declared as being replaced can be a virtual | package, so for example, all mail transport agents (MTAs) would have the | following fields in their control files: | | Provides: mail-transport-agent | Conflicts: mail-transport-agent | Replaces: mail-transport-agent | | ensuring that only one MTA can be unpacked at any one time Seems like something to try to see if it fixes the issue. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores) 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 libmarco-private1 depends on: ii libatk1.0-0 2.28.1-1 ii libc6 2.27-3 ii libcairo-gobject2 1.15.10-3 ii libcairo2 1.15.10-3 ii libcanberra-gtk3-00.30-6 ii libcanberra0 0.30-6 ii libgdk-pixbuf2.0-02.36.11-2 ii libglib2.0-0 2.56.1-2 ii libgtk-3-03.22.29-3 ii libgtop-2.0-112.38.0-2 ii libice6 2:1.0.9-2 ii libpango-1.0-01.42.0-1 ii libpangocairo-1.0-0 1.42.0-1 ii libsm62:1.2.2-1+b3 ii libstartup-notification0 0.12-5 ii libx11-6 2:1.6.5-1 ii libxcomposite11:0.4.4-2 ii libxcursor1 1:1.1.15-1 ii libxdamage1 1:1.1.4-3 ii libxext6 2:1.3.3-1+b2 ii libxfixes31:5.0.3-1 ii libxinerama1 2:1.1.3-1+b3 ii libxpresent1 1.0.0-2+b10 ii libxrandr22:1.5.1-1 ii libxrender1 1:0.9.10-1 libmarco-private1 recommends no packages. libmarco-private1 suggests no packages. -- no debconf information
Bug#897345: libosmo-ranap-dev claims to be Multi-Arch: same but is not
Package: libosmo-ranap-dev Version: 0.2.0-1 Severity: normal Dear Maintainer, Trying to install the amd64 and i386 versions of this package results in the following error: # apt-get install libosmo-ranap-dev:amd64 libosmo-ranap-dev:i386 [...] Unpacking libosmo-ranap-dev:i386 (0.2.0-1) ... dpkg: error processing archive /var/cache/apt/archives/libosmo-ranap-dev_0.2.0-1_i386.deb (--unpack): trying to overwrite shared '/usr/include/osmocom/ranap/ranap_ies_defs.h', which is different from other instances of package libosmo-ranap-dev:i386 Errors were encountered while processing: /var/cache/apt/archives/libosmo-ranap-dev_0.2.0-1_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores) 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 libosmo-ranap-dev depends on: ii libosmo-ranap1 0.2.0-1 libosmo-ranap-dev recommends no packages. libosmo-ranap-dev suggests no packages. -- no debconf information
Bug#897343: libpfm4-dev claims to be Multi-Arch: same but is not
Package: libpfm4-dev Version: 4.9.0+git21-gc4de2ea-1 Severity: normal Dear Maintainer, Trying to install the amd64 and i386 versions of this package results in the following error: # apt-get install libpfm4-dev:amd64 libpfm4-dev:i386 [...] Unpacking libpfm4-dev:i386 (4.9.0+git21-gc4de2ea-1) ... dpkg: error processing archive /var/cache/apt/archives/libpfm4-dev_4.9.0+git21-gc4de2ea-1_i386.deb (--unpack): trying to overwrite shared '/usr/share/doc/libpfm4-dev/examples/check_events.gz', which is different from other instances of package libpfm4-dev:i386 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/libpfm4-dev_4.9.0+git21-gc4de2ea-1_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores) 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 libpfm4-dev depends on: ii libpfm4 4.9.0+git21-gc4de2ea-1 libpfm4-dev recommends no packages. libpfm4-dev suggests no packages. -- no debconf information
Bug#897344: libvisual-0.4-dev claims to be Multi-Arch: same but is not
Package: libvisual-0.4-dev Version: 0.4.0-11 Severity: normal Dear Maintainer, Trying to install the amd64 and i386 versions of this package results in the following error: # apt-get install libvisual-0.4-dev:amd64 libvisual-0.4-dev:i386 [...] Unpacking libvisual-0.4-dev:i386 (0.4.0-11) ... dpkg: error processing archive /var/cache/apt/archives/libvisual-0.4-dev_0.4.0-11_i386.deb (--unpack): trying to overwrite shared '/usr/include/libvisual-0.4/libvisual/lvconfig.h', which is different from other instances of package libvisual-0.4-dev:i386 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/libvisual-0.4-dev_0.4.0-11_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores) 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 libvisual-0.4-dev depends on: ii libc6-dev [libc-dev] 2.27-3 ii libvisual-0.4-0 0.4.0-11 ii pkg-config0.29-4+b1 libvisual-0.4-dev recommends no packages. libvisual-0.4-dev suggests no packages. -- no debconf information
Bug#897339: libtorch-th-dev claims to be Multi-Arch: same but is not
Package: libtorch-th-dev Version: 0~20170926-g89ede3b-2 Severity: normal Dear Maintainer, Trying to install the amd64 and i386 versions of this package results in the following error: # apt-get install libtorch-th-dev:amd64 libtorch-th-dev:i386 [...] Unpacking libtorch-th-dev:i386 (0~20170926-g89ede3b-2) ... dpkg: error processing archive /var/cache/apt/archives/libtorch-th-dev_0~20170926-g89ede3b-2_i386.deb (--unpack): trying to overwrite shared '/usr/include/TH/THGeneral.h', which is different from other instances of package libtorch-th-dev:i386 Errors were encountered while processing: /var/cache/apt/archives/libtorch-th-dev_0~20170926-g89ede3b-2_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores) 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 libtorch-th-dev depends on: ii libtorch-th 0~20170926-g89ede3b-2 libtorch-th-dev recommends no packages. libtorch-th-dev suggests no packages. -- no debconf information
Bug#897341: libjson-glib-dev claims to be Multi-Arch: same but is not
Package: libjson-glib-dev Version: 1.4.2-3 Severity: normal Dear Maintainer, Trying to install the amd64 and i386 versions of this package results in the following error: # apt-get install libjson-glib-dev:amd64 libjson-glib-dev:i386 [...] Unpacking libjson-glib-dev:i386 (1.4.2-3) ... dpkg: error processing archive /var/cache/apt/archives/libjson-glib-dev_1.4.2-3_i386.deb (--unpack): trying to overwrite shared '/usr/include/json-glib-1.0/json-glib/json-enum-types.h', which is different from other instances of package libjson-glib-dev:i386 Errors were encountered while processing: /var/cache/apt/archives/libjson-glib-dev_1.4.2-3_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores) 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 libjson-glib-dev depends on: ii gir1.2-json-1.0 1.4.2-3 ii libglib2.0-dev 2.56.1-2 ii libjson-glib-1.0-0 1.4.2-3 ii pkg-config 0.29-4+b1 libjson-glib-dev recommends no packages. Versions of packages libjson-glib-dev suggests: pn libjson-glib-doc -- no debconf information
Bug#897340: libcidr-dev claims to be Multi-Arch: same but is not
Package: libcidr-dev Version: 1.2.3-2 Severity: normal Dear Maintainer, Trying to install the amd64 and i386 versions of this package results in the following error: # apt-get install libcidr-dev:amd64 libcidr-dev:i386 [...] Unpacking libcidr-dev:i386 (1.2.3-2) ... dpkg: error processing archive /var/cache/apt/archives/libcidr-dev_1.2.3-2_i386.deb (--unpack): trying to overwrite shared '/usr/share/doc/libcidr-dev/examples/acl/GNUmakefile', which is different from other instances of package libcidr-dev:i386 Errors were encountered while processing: /var/cache/apt/archives/libcidr-dev_1.2.3-2_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores) 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 libcidr-dev depends on: ii libcidr0 1.2.3-2 libcidr-dev recommends no packages. libcidr-dev suggests no packages. -- no debconf information
Bug#897342: libmstch-dev claims to be Multi-Arch: same but is not
Package: libmstch-dev Version: 1.0.2-2 Severity: normal Dear Maintainer, Trying to install the amd64 and i386 versions of this package results in the following error: # apt-get install libmstch-dev:amd64 libmstch-dev:i386 [...] Unpacking libmstch-dev:i386 (1.0.2-2) ... dpkg: error processing archive /var/cache/apt/archives/libmstch-dev_1.0.2-2_i386.deb (--unpack): trying to overwrite shared '/usr/lib/cmake/mstch/mstch-config-version.cmake', which is different from other instances of package libmstch-dev:i386 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/libmstch-dev_1.0.2-2_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores) 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 libmstch-dev depends on: ii libboost-dev 1.62.0.1 libmstch-dev recommends no packages. libmstch-dev suggests no packages. -- no debconf information
Bug#897326: libignition-transport4-dev claims to be Multi-Arch: same but is not
Package: libignition-transport4-dev Version: 4.0.0+dfsg-4 Severity: normal Dear Maintainer, Trying to install the amd64 and i386 versions of this package results in the following error: # apt-get install libignition-transport4-dev:amd64 libignition-transport4-dev:i386 [...] Unpacking libignition-transport4-dev:i386 (4.0.0+dfsg-4) ... dpkg: error processing archive /var/cache/apt/archives/libignition-transport4-dev_4.0.0+dfsg-4_i386.deb (--unpack): trying to overwrite shared '/usr/lib/ruby/ignition/cmdtransport4.rb', which is different from other instances of package libignition-transport4-dev:i386 Errors were encountered while processing: /var/cache/apt/archives/libignition-transport4-dev_4.0.0+dfsg-4_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores) 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 libignition-transport4-dev depends on: ii libignition-cmake-dev 0.4.1-1 ii libignition-msgs-dev1.0.0+dfsg1-5 ii libignition-transport4 4.0.0+dfsg-4 ii libprotobuf-dev 3.0.0-9.1 ii libzmq3-dev 4.2.5-1 ii uuid-dev2.31.1-0.5 libignition-transport4-dev recommends no packages. libignition-transport4-dev suggests no packages. -- no debconf information
Bug#897324: libbellesip-dev claims to be Multi-Arch: same but is not
Package: libbellesip-dev Version: 1.6.3-2 Severity: normal Dear Maintainer, Trying to install the amd64 and i386 versions of this package results in the following error: # apt-get install libbellesip-dev:amd64 libbellesip-dev:i386 [...] Unpacking libbellesip-dev:i386 (1.6.3-2) ... dpkg: error processing archive /var/cache/apt/archives/libbellesip-dev_1.6.3-2_i386.deb (--unpack): trying to overwrite shared '/usr/share/BelleSIP/cmake/BelleSIPConfigVersion.cmake', which is different from other instances of package libbellesip-dev:i386 Errors were encountered while processing: /var/cache/apt/archives/libbellesip-dev_1.6.3-2_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores) 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 libbellesip-dev depends on: ii libbellesip0 1.6.3-2 libbellesip-dev recommends no packages. libbellesip-dev suggests no packages. -- no debconf information
Bug#897328: libgeocode-glib-dev claims to be Multi-Arch: same but is not
Package: libgeocode-glib-dev Version: 3.25.4.1-4 Severity: normal Dear Maintainer, Trying to install the amd64 and i386 versions of this package results in the following error: # apt-get install libgeocode-glib-dev:amd64 libgeocode-glib-dev:i386 [...] Unpacking libgeocode-glib-dev:i386 (3.25.4.1-4) ... dpkg: error processing archive /var/cache/apt/archives/libgeocode-glib-dev_3.25.4.1-4_i386.deb (--unpack): trying to overwrite shared '/usr/include/geocode-glib-1.0/geocode-glib/geocode-enum-types.h', which is different from other instances of package libgeocode-glib-dev:i386 Errors were encountered while processing: /var/cache/apt/archives/libgeocode-glib-dev_3.25.4.1-4_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores) 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 libgeocode-glib-dev depends on: ii gir1.2-geocodeglib-1.0 3.25.4.1-4 ii libgeocode-glib03.25.4.1-4 ii libglib2.0-dev 2.56.1-2 libgeocode-glib-dev recommends no packages. Versions of packages libgeocode-glib-dev suggests: pn libgeocode-glib-doc -- no debconf information
Bug#897325: guile-2.2-libs claims to be Multi-Arch: same but is not
Package: guile-2.2-libs Version: 2.2.3+1-3 Severity: normal Dear Maintainer, Trying to install the amd64 and i386 versions of this package results in the following error: # apt-get install guile-2.2-libs:amd64 guile-2.2-libs:i386 [...] Unpacking guile-2.2-libs:i386 (2.2.3+1-3) ... dpkg: error processing archive /var/cache/apt/archives/guile-2.2-libs_2.2.3+1-3_i386.deb (--unpack): trying to overwrite shared '/usr/share/lintian/overrides/guile-2.2-libs', which is different from other instances of package guile-2.2-libs:i386 Errors were encountered while processing: /var/cache/apt/archives/guile-2.2-libs_2.2.3+1-3_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores) 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 guile-2.2-libs depends on: ii libc6 2.27-3 ii libffi63.2.1-8 ii libgc1c2 1:7.4.2-8 ii libgmp10 2:6.1.2+dfsg-3 ii libltdl7 2.4.6-2.1 ii libncurses56.1-1 ii libreadline7 7.0-3 ii libtinfo5 6.1-1 ii libunistring2 0.9.8-1 guile-2.2-libs recommends no packages. guile-2.2-libs suggests no packages. -- no debconf information
Bug#897329: libchemps2-dev claims to be Multi-Arch: same but is not
Package: libchemps2-dev Version: 1.8.7-1 Severity: normal Dear Maintainer, Trying to install the amd64 and i386 versions of this package results in the following error: # apt-get install libchemps2-dev:amd64 libchemps2-dev:i386 [...] Preparing to unpack .../libchemps2-dev_1.8.7-1_i386.deb ... Unpacking libchemps2-dev:i386 (1.8.7-1) ... dpkg: error processing archive /var/cache/apt/archives/libchemps2-dev_1.8.7-1_i386.deb (--unpack): trying to overwrite shared '/usr/share/cmake/CheMPS2/CheMPS2Config.cmake', which is different from other instances of package libchemps2-dev:i386 Errors were encountered while processing: /var/cache/apt/archives/libchemps2-dev_1.8.7-1_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores) 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 libchemps2-dev depends on: ii libchemps2-3 1.8.7-1 libchemps2-dev recommends no packages. Versions of packages libchemps2-dev suggests: pn chemps2-doc -- no debconf information
Bug#897327: libcdio-dev claims to be Multi-Arch: same but is not
Package: libcdio-dev Version: 1.0.0-2 Severity: normal Dear Maintainer, Trying to install libcdio-dev:amd64 and libcdio-dev:i386 results in the following error: # apt-get install libcdio-dev:amd64 libcdio-dev:i386 [...] Unpacking libcdio-dev:i386 (1.0.0-2) ... dpkg: error processing archive /var/cache/apt/archives/libcdio-dev_1.0.0-2_i386.deb (--unpack): trying to overwrite shared '/usr/include/cdio/cdio_config.h', which is different from other instances of package libcdio-dev:i386 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/libcdio-dev_1.0.0-2_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores) 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 libcdio-dev depends on: ii dpkg 1.19.0.5 ii install-info 6.5.0.dfsg.1-2 ii libc6-dev [libc-dev] 2.27-3 ii libcdio17 1.0.0-2 libcdio-dev recommends no packages. libcdio-dev suggests no packages. -- no debconf information
Bug#897224: libsigrokdecode2 breaks package system in multiarch setting
Package: libsigrokdecode2 Version: 0.3.0-1+b3 Severity: important Dear Maintainer, libsigrokdecode2 is marked as Multi-Arch: same but its postinst and preinst scripts call pycompile and pyclean without specifying the package architecture. As a result if libsigrokdecode2 is installed for more than one architecture the package name is ambiguous, causing the postinst and prerm scripts fail. This then prevents any package from being installed or removed, thus breaking the system permanently. The solution is to replace the following line in /var/lib/dpkg/info/libsigrokdecode2:*.postinst py3compile -p libsigrokdecode2 /usr/share/libsigrokdecode2 -V 3.2- with py3compile -p libsigrokdecode2:$DPKG_MAINTSCRIPT_ARCH /usr/share/libsigrokdecode2 -V 3.2- And the following lines in /var/lib/dpkg/info/libsigrokdecode2:*.prerm py3clean -p libsigrokdecode2 else dpkg -L libsigrokdecode2 | perl -ne 's,/([^/]*)\.py$,/__pycache__/\1.*, or next; unlink $_ or die $! foreach glob($_)' with: py3clean -p libsigrokdecode2:$DPKG_MAINTSCRIPT_ARCH else dpkg -L libsigrokdecode2:$DPKG_MAINTSCRIPT_ARCH | perl -ne 's,/([^/]*)\.py$,/__pycache__/\1.*, or next; unlink $_ or die $! foreach glob($_)' Note that this bugs still affects Debian 9.4, the current stable release. See also bug #770625 which shows how this same bug was fixed in gir1.2-ibus-1.0. -- System Information: Debian Release: 9.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) 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) Versions of packages libsigrokdecode2:amd64 depends on: ii libc6 2.24-11+deb9u3 ii libglib2.0-0 2.50.3-2 ii libpython3.5 3.5.3-1 ii python3 3.5.3-1 libsigrokdecode2:amd64 recommends no packages. libsigrokdecode2:amd64 suggests no packages. -- no debconf information
Bug#897223: python-kmodpy breaks package system in multiarch setting
Package: python-kmodpy Version: 0.1.10-2 Severity: important Dear Maintainer, python-kmodpy is marked as Multi-Arch: same but its postinst and preinst scripts call pycompile and pyclean without specifying the package architecture. As a result if python-kmodpy is installed for more than one architecture the package name is ambiguous, causing the postinst and prerm scripts fail. This then prevents any package from being installed or removed, thus breaking the system permanently. The solution is to replace the following line in /var/lib/dpkg/info/libccnet0:*.postinst pycompile -p python-kmodpy with pycompile -p python-kmodpy:$DPKG_MAINTSCRIPT_ARCH And the following line in /var/lib/dpkg/info/libccnet0:*.prerm pyclean -p python-kmodpy with pyclean -p python-kmodpy:$DPKG_MAINTSCRIPT_ARCH Note that this bugs still affects Debian 9.4, the current stable release. See also bug #770625 which shows how this same bug was fixed in gir1.2-ibus-1.0. -- System Information: Debian Release: 9.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) 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) Versions of packages python-kmodpy:amd64 depends on: ii libkmod2 23-2 ii python2.7.13-2 python-kmodpy:amd64 recommends no packages. python-kmodpy:amd64 suggests no packages. -- no debconf information
Bug#897206: libccnet0:amd64: libccnet0 breaks package system in multiarch setting
Package: libccnet0 Version: 6.0.2-2 Severity: important Dear Maintainer, libccnet0 is marked as Multi-Arch: same but its postinst and preinst scripts call pycompile and pyclean without specifying the package architecture. As a result if libccnet0 is installed for more than one architecture the package name is ambiguous, causing the postinst and prerm scripts fail. This then prevents any package from being installed or removed, thus breaking the system permanently. The solution is to replace the following line in /var/lib/dpkg/info/libccnet0:*.postinst pycompile -p libccnet0 with pycompile -p libccnet0:$DPKG_MAINTSCRIPT_ARCH And the following line in /var/lib/dpkg/info/libccnet0:*.prerm pyclean -p libccnet0 with pyclean -p libccnet0:$DPKG_MAINTSCRIPT_ARCH See also bug #770625 which shows how this same bug was fixed in gir1.2-ibus-1.0. -- System Information: Debian Release: 9.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) 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) Versions of packages libccnet0:amd64 depends on: ii libc6 2.24-11+deb9u3 ii libevent-2.0-5 2.0.21-stable-3 it libglib2.0-02.50.3-2 ii libjansson4 2.9-1 ii libsearpc1 3.0.8-1 ii libsqlite3-03.16.2-5+deb9u1 ii libuuid12.29.2-1+deb9u1 ii python 2.7.13-2 ii python-searpc 3.0.8-1 libccnet0:amd64 recommends no packages. libccnet0:amd64 suggests no packages. -- no debconf information
Bug#770265: gir1.2-ibus-1.0: fails to install in multiarch setting: dpkg-query --listfiles called with ambiguous package name (fwd)
severity #770265 critical And the reason why it should really really be fixed in Debian 9.4 is because it's a critical bug: anyone running into it will end up with a totally broken packaging system, that is one where no package can be added or removed. 1 criticalmakes unrelated software on the system (or the whole system) break, [...] on systems where you install the package. -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ In theory, theory and practice are the same, but in practice they're different.
Bug#895518: libsdl2-dev is not Multi-Arch compatible
Sorry, I mixed things up. On Debian Testing libsdl2-dev (2.0.8+dfsg1-1) supports multiarch and it's libxkbcommon-dev that ruins it for everyone (see bug 893855). But I'm also working on a Debian 9.4 VM and there libsdl2-dev 2.0.5+dfsg1-2 does not support multiarch. I got confused and thought both issues had the same source. So while I'd still really like libsdl2-dev to support multiarch in Debian Stable (because that's what people are told to use after all and it would be consistent with point 4 of the Social Contract[1]), I can understand if this bug gets closed. [1] We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environments. https://www.debian.org/social_contract -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.
Bug#895518: libsdl2-dev is not Multi-Arch compatible
Package: libsdl2-dev Version: 2.0.8+dfsg1-1 Severity: normal Dear Maintainer, The development package is not multiarch aware which causes the amd64 version to conflict with the i386 one, thus making it impossible to install both. As a result the /usr/lib/i386-linux-gnu/libSDL2.so symbolic link is missing so that developping 32 bit applications that use this library is impossible on a 64 bit system. In particular this makes development of the Wine project really painful on Debian as Wine really needs both 32 and 64 bit support since most 64 bit Windows applications have a 32 bit installer. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libsdl2-dev depends on: ii libasound2-dev 1.1.3-5 ii libdbus-1-dev 1.12.6-2 ii libegl1-mesa-dev 17.3.7-1 ii libgl1-mesa-dev17.3.7-1 ii libgles2-mesa-dev 17.3.7-1 ii libglu1-mesa-dev 9.0.0-3 ii libibus-1.0-dev1.5.18-1 ii libpulse-dev 11.1-4 ii libsdl2-2.0-0 2.0.8+dfsg1-1 ii libsndio-dev 1.1.0-3 ii libudev-dev238-4 ii libwayland-dev 1.14.0-2 ii libx11-dev 2:1.6.5-1 ii libxcursor-dev 1:1.1.15-1 ii libxext-dev2:1.3.3-1+b2 ii libxi-dev 2:1.7.9-1 ii libxinerama-dev2:1.1.3-1+b3 ii libxkbcommon-dev 0.8.0-1 ii libxrandr-dev 2:1.5.1-1 ii libxss-dev 1:1.2.2-1+b2 ii libxt-dev 1:1.1.5-1 ii libxv-dev 2:1.0.11-1 ii libxxf86vm-dev 1:1.1.4-1+b2 libsdl2-dev recommends no packages. libsdl2-dev suggests no packages. -- no debconf information
Bug#770265: gir1.2-ibus-1.0: fails to install in multiarch setting: dpkg-query --listfiles called with ambiguous package name
reopen #770265 This bug is still present in Debian 9.4 which is the official stable release of Debian, the one that people are supposed to use. This despite the bug being known 4 years before the Debian 9.4 release! This despite the bug breaking package management! This despite a fix being known and implemented! So until this bug is fixed in the Debian release everyone uses I don't think it should be closed. -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ In theory, theory and practice are the same, but in practice they're different.
Bug#884707: apparmor breaks clamdscan
On Sun, 7 Jan 2018, intrigeri wrote: [...] > The alternatives are not very compelling, they are > basically: either give up on path-based LSM entirely or make the > AppArmor policy wide enough to accommodate all kinds of needs; in both > cases, we lose security benefits of the majority of users for whom the > current profile would work just fine, which is sad. I don't see how the AppArmor profile improves security. I assume the goal is to either prevent remote attacks, local privilege escalations or limit damage after a compromise. For a remote attack the exploit is likely to come in the form of an email attachment or a link to a malicious file that will get saved to ~/Downloads. Both locations are allows by the AppArmor profile so that these exploits will reach their targets (clamd). Plus, as pointed out before, any file saved in a location out of reach of clamd will instead be able to attack the user account without risking detection. For a local privilege escalation, the attacker can simply use --fdpass to bypass the path-based AppArmor restrictions. So again the Apprmor profile provides no benefit. So now what about mitigating the damage that can be done by compromising the clamd process? What kind of damage can be done? * Making the clamd process inoperative so other exploits can slip undetected. -> The AppArmor profile cannot prevent that. * Leaking sensitive files. -> The clamd process runs in the clamav account and thus does not have more privileged access to sensitive files than any other accounts with the exception of the clamav files. But the AppArmor grants read access to all the clamav files so it does not help here either. * Poisonning the clamav virus database to disable it. -> The AppArmor profile allows write access to the /var/lib/clamav/* files which, if I understand correctly, is where the virus database files are. So it does not help for this either. * Using clamd to perform other system attacks. -> The system vulnerabilities are not going to be more exploitable from the clamd process than from any other user account. So the AppArmor is no help for local privilege exploits but could help mitigate the damage caused by remote attacks. -> That's as long as users use clamd rather than clamscan which is not protected by any AppArmor profile. I think the basic mistake is treating clamd as if it was a web or database server. Database servers are supposed to only use a very limited set of files so an AppArmor profile limiting them to that set of files makes sense. But the whole purpose of an anti-virus is being able to check *any* file on the system. Any place that the anti-virus cannot check is a place that an attacker can use to put an exploit that won't be detected. That was a big part of the issue with the Sony rootkit. That ClamAV is doing it to itself makes it no better. The profile would make sense if clamd is only used remotely rather than to scan local files. -- Francois Gouget <fgou...@free.fr> http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.
Bug#769019: aspell-te: Invalid file format for /usr/lib/aspell/te.rws
Package: aspell-te Version: 0.01-2-5 Followup-For: Bug #769019 Dear Maintainer, There has been no release in almost *6* years! (and thus no fix for this bug) Has this package been abandonned? Time to remove it from Debian? -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages aspell-te depends on: ii aspell 0.60.7~20110707-4 ii dictionaries-common 1.27.2 aspell-te recommends no packages. aspell-te suggests no packages. -- no debconf information
Bug#769017: aspell-or: Invalid file format for /usr/lib/aspell/or.rws
Package: aspell-or Version: 0.03-1-5 Followup-For: Bug #769017 Dear Maintainer, There has been no release in almost *6* years! (and thus no fix for this 3 years old bug) Has this package been abandonned? Time to remove it from Debian? -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages aspell-or depends on: ii aspell 0.60.7~20110707-4 ii dictionaries-common 1.27.2 aspell-or recommends no packages. aspell-or suggests no packages. -- no debconf information
Bug#769018: aspell-pa: Invalid file format for /usr/lib/aspell/pa.rws
Package: aspell-pa Followup-For: Bug #769018 Dear Maintainer, This bug is fixed in 0.01-1-5 and should be closed. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages aspell-pa depends on: ii aspell 0.60.7~20110707-4 ii dictionaries-common 1.27.2 aspell-pa recommends no packages. aspell-pa suggests no packages. -- no debconf information
Bug#884707: apparmor breaks clamdscan
or configuration is going to be different, getting such a modification working everywhere is likely going to be impractical, and having a third-party package 'water down' the apparmor configuration in some people's opinion presents obvious ethical issues). * Use clamscan instead of clamdscan. However clamscan is really slow which has a particularly significant impact on small files. For instance on my laptop it takes over 9 seconds for clamscan to analyze a 242 *bytes* file, while clamdscan does it in under 0.1 second (and 4 millisecond on the second run). This would also really impact the CrossOver use case. * Try to detect when clamdscan fails with an exit code of 2 and try again with clamscan. This would limit the impact of clamscan's poor performance. But this means introducing a lot of complication everywhere that clamdscan is used. * Use 'clamdscan --fdpass'. This completely bypasses the apparmor profile. What are the security implications of that? As far as I can tell it's not possible to reopen an existing fd with different access bits so if clamdscan opens the file to be scanned in read-only mode, then clamd should not be able to write to it. So why not make --fdpass the default? -- Francois Gouget <fgou...@free.fr>
Bug#831607: mbl.ndb database integrity test fails every time and causes cron spam
Package: clamav-unofficial-sigs Version: 3.7.2-2 Followup-For: Bug #831607 Dear Maintainer, This bug is still present which makes sense given that this package is totally unmaintained: the last release was in 2014!!! I believe the simplest workaorund is to rename the mbl_dbs variable in /usr/share/clamav-unofficial-sigs/conf.d/00-clamav-unofficial-sigs.conf: ignore_mbl_dbs=" mbl.ndb " -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages clamav-unofficial-sigs depends on: ii bind9-host [host] 1:9.11.2+dfsg-5 ii clamav 0.99.3~beta1+dfsg-4 ii curl 7.57.0-1 ii dnsutils 1:9.11.2+dfsg-5 ii gnupg 2.2.3-1 ii rsync 3.1.2-2.1 clamav-unofficial-sigs recommends no packages. Versions of packages clamav-unofficial-sigs suggests: ii clamav-daemon 0.99.3~beta1+dfsg-4 -- no debconf information
Bug#884707: apparmor breaks clamdscan
Package: apparmor Version: 2.11.1-4 Severity: important Dear Maintainer, After upgrading from apparmor 2.11.1-2 to 2.11.1-4 I cannot use clamdscan anymore; $ ll -d /bin /bin/true drwxr-xr-x 2 root root 4,0K déc. 14 18:26 /bin -rwxr-xr-x 1 root root 31K oct. 2 19:51 /bin/true $ clamdscan /bin/true /bin/true: Can't open file or directory ERROR --- SCAN SUMMARY --- Infected files: 0 Total errors: 1 Time: 0.004 sec (0 m 0 s) Such a command should have been successful. As far as I can tell this error is caused by /etc/apparmor.d/usr.sbin.clamd which, IMO, puts undue restrictions on the Clam-AV operations. Note that I did not install apparmor by choice: it was brought in by linux-image-4.13. It's not like I asked for it but it appears now I will have to learn how to fix its configuration :-( -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages apparmor depends on: ii debconf [debconf-2.0] 1.5.65 ii libc6 2.25-3 ii lsb-base 9.20170808 ii python33.6.3-2 apparmor recommends no packages. Versions of packages apparmor suggests: pn apparmor-profiles pn apparmor-profiles-extra pn apparmor-utils -- debconf information: apparmor/homedirs:
