Bug#907592: global: gtags doesn't generate tags for R sources

[Punit Agrawal]

fixed 907592 6.6.5-1

On Tue, 1 Jan 2019 13:42:21 +0900 Punit Agrawal  wrote:
> A pull request updating the lexer for R has been recently merged
> upstream[0]. As this issue is due to incorrect parsing, it is worth
> investigating whether the improved lexer helps with $SUBJECT.
>
> [0] 
> https://bitbucket.org/birkenfeld/pygments-main/pull-requests/680/slexer-improvements/diff

It seems that the referenced changes have been merged and are also
available in debian[1].
Marking as fixed.

Please feel free to re-open if there's anything that is needed in this
package regarding this issue.

Thanks,
Punit

[1] https://tracker.debian.org/pkg/pygments

Bug#973679: python3-audioread: Broken with GStreamer 1.18

[Tobias Gruetzmacher]

Package: python3-audioread
Version: 2.1.8
Severity: important

Hi,

the GStreamer 1.18 Python API has broken this library for some usecases,
notibly importing files into beets, see:

- https://github.com/beetbox/audioread/pull/110
- https://github.com/beetbox/pyacoustid/issues/61
- https://github.com/beetbox/beets/issues/3775

It would be nice to get an updated Debian package, so that beets works
again.

Regards, Tobias


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=de:en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-audioread depends on:
ii  ffmpeg   7:4.3.1-5
ii  python3  3.8.6-1

python3-audioread recommends no packages.

python3-audioread suggests no packages.

-- no debconf information

Bug#973677: libkscreenlocker5: No login dialog is shown, user cannot unlock session

[Mikko Korhonen]

Package: libkscreenlocker5
Version: 5.17.5-2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: mjkor...@gmail.com

This is same as
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852162
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904074
but happens every time and at any unlock, not just on dehibernation and with a 
single monitor: only the cursor is shown on a black screen and there is no way 
to login.

As a workaround killing the process helps as the new instance shows the login 
screen.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-3-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libkscreenlocker5 depends on:
ii  kpackagetool5  5.74.0-2
ii  libc6  2.31-4
ii  libkf5configcore5  5.74.0-2
ii  libkf5configgui5   5.74.0-2
ii  libkf5coreaddons5  5.74.0-2
ii  libkf5crash5   5.74.0-2
ii  libkf5declarative5 5.74.0-2
ii  libkf5globalaccel-bin  5.74.0-2
ii  libkf5globalaccel5 5.74.0-2
ii  libkf5i18n55.74.0-3
ii  libkf5idletime55.74.0-2
ii  libkf5notifications5   5.74.0-2
ii  libkf5package5 5.74.0-2
ii  libkf5quickaddons5 5.74.0-2
ii  libkf5waylandclient5   4:5.74.0-2
ii  libkf5waylandserver5   4:5.74.0-2
ii  libkf5windowsystem55.74.0-2
ii  libpam0g   1.3.1-5
ii  libqt5core5a   5.14.2+dfsg-6
ii  libqt5dbus55.14.2+dfsg-6
ii  libqt5gui5 5.14.2+dfsg-6
ii  libqt5network5 5.14.2+dfsg-6
ii  libqt5qml5 5.14.2+dfsg-3
ii  libqt5quick5   5.14.2+dfsg-3
ii  libqt5widgets5 5.14.2+dfsg-6
ii  libqt5x11extras5   5.14.2-2
ii  libseccomp22.4.4-1+b1
ii  libstdc++6 10.2.0-15
ii  libwayland-client0 1.18.0-2~exp1.1
ii  libwayland-server0 1.18.0-2~exp1.1
ii  libx11-6   2:1.6.12-1
ii  libxcb-keysyms10.4.0-1+b2
ii  libxcb11.14-2
ii  libxi6 2:1.7.10-1
ii  psmisc 23.3-1

Versions of packages libkscreenlocker5 recommends:
ii  kde-config-screenlocker  5.17.5-2

libkscreenlocker5 suggests no packages.

-- no debconf information

Bug#940914: uno-libs3: Segfault on launch in cppu::_copyConstructAnyFromData

[rene]

Hi,

Am 2. November 2020 17:59:04 MEZ schrieb Rene Engelhard :
>Hmm, no, works here. (pure sid chroot + apt install libreoffice

For avoidance of doubt: yes, also apt install libreoffice-l10n-* and 
libreoffice-help-* of course

> + apt
>install mythes

And mythes-* here of course.

Regards,

Rene

Bug#973623: stack overflows with ghc on ppc64el

[Matthias Klose]

the patch mentioned above is already part of bintuils 2.35.1-2.

Bug#973562: wordpress: Wordpress 5.5.2 security release

[Utkarsh Gupta]

Hi Craig,

On Tue, Nov 3, 2020 at 12:00 PM Craig Small  wrote:
> Hi Utkarsh, I've got Sid uploading now and will start on Buster in a moment.

Perfect! Thanks for your great work on wordpress!


 - u

Bug#972429: djview4: djview4 as a server

[Janusz S. Bień]

Looks like the server part of External Application Button is ready for
packaging in Debian:

https://github.com/andy-portmen/native-client

What about making the package an official one?

Regards

Janusz

-- 
 ,   
Janusz S. Bien
emeryt (emeritus)
https://sites.google.com/view/jsbien

Bug#973674: buster-pu: package mdadm/4.1-8

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Mon, 2020-11-02 at 20:05 -0800, Felix Lechner wrote:
> The mdadm version in buster suffers from Bug#960132, which a reporter
> assessed at the serious level. It was fixed version 4.1-6, but the
> version 4.1-8 that is currently in testing includes many new
> translations and is probably a better candidate.

"Many new translations" doesn't particularly make a package a good
candidate for a stable update. Hardening changes, feature additions and
a debhelper bump to a version that's not even in stable certainly
don't.

The intent of a stable update is to make the changes required to fix
the issue being discussed, which in most cases does not mean pulling in
a new version of the package from testing.

> I believe it is my responsibility per section 3.1.2 of the
> Developer's Reference to bring this matter to your attention.

That is correct, but as per section 5.5.1 this bug report should also
include a debdiff of the package you're proposing to upload, containing
the "minimal and relevant" fix. (3.1.2 also mentions "providing a
targeted fix".)

The example debdiff that a commenter provided in #960132 is more of the
type that we'd generally expect, with the assumption that the proposer
of a p-u bug has produced said debdiff by building and testing the
package in a stable environment.

Regards,

Adam

Bug#973676: ProtocolsHonorOrder Off by default?

[Harald Dunkel]

Package: apache2
Version: 2.4.46-1
Severity: wishlist

AFAIU it is good practice to respect the client's preferences, so you
might want to consider to set

ProtocolsHonorOrder Off

in http2.conf by default, similar to SSLHonorCipherOrder.

Next step would be to enable http/2 by default. Setting ProtocolsHonorOrder
Off by default could reduce the risk.


Regards
Harri

Bug#973675: mesa: Fix warnings for deprecated options

[Stuart Young]

Package: mesa
Version: 20.2.1-1

Attached is a patch that fixes a bunch of warnings about
deprecated commands along the lines of:
 option "true" deprecated, please use "enabled" instead.
 option "false" deprecated, please use "disabled" instead.

Suspect that these changes will become mandatory in the future, so best to
get the warnings sorted now.

Tested build on amd64.

Note: Doesn't seem to affect all options that take true/false, or at least
the ones that affect amd64.

-- 
Stuart Young (aka Cefiar)
--- a/debian/rules	2020-11-03 06:03:30.0 +
+++ b/debian/rules	2020-11-03 06:01:29.350023534 +
@@ -34,7 +34,7 @@
 GALLIUM_DRIVERS =
 VULKAN_DRIVERS =
 
-confflags_DRI3 = -Ddri3=false
+confflags_DRI3 = -Ddri3=disabled
 
 # hurd doesn't do direct rendering
 ifeq ($(DEB_HOST_ARCH_OS), hurd)
@@ -42,7 +42,7 @@
 	EGL_PLATFORMS = x11
 
 	confflags_DIRECT_RENDERING = -Dglx-direct=false
-	confflags_GBM = -Dgbm=false
+	confflags_GBM = -Dgbm=disabled
 	confflags_OSMESA = -Dosmesa=classic
 else
 	DRI_DRIVERS += r200,r100
@@ -56,7 +56,7 @@
   endif
 
   ifeq ($(DEB_HOST_ARCH_OS), linux)
-	confflags_DRI3 = -Ddri3=true
+	confflags_DRI3 = -Ddri3=enabled
 	DRI_DRIVERS += ,nouveau
 	# Gallium drivers which require kernel support, not yet ported to non-Linux
 	GALLIUM_DRIVERS += ,nouveau,virgl
@@ -74,7 +74,7 @@
 	ifneq (,$(filter $(DEB_HOST_ARCH), amd64 i386 x32))
 		GALLIUM_DRIVERS += ,svga,zink
 		# svga needs xa state tracker
-		confflags_GALLIUM += -Dgallium-xa=true
+		confflags_GALLIUM += -Dgallium-xa=enabled
 		VULKAN_DRIVERS += ,intel
 	endif
 
@@ -82,7 +82,7 @@
 	EGL_PLATFORMS += ,wayland
 
 	ifneq (,$(filter $(DEB_HOST_ARCH), amd64 arm64 armhf i386 mips64el mipsel powerpc ppc64 ppc64el s390x))
-		confflags_VALGRIND += -Dvalgrind=true
+		confflags_VALGRIND += -Dvalgrind=enabled
 	endif
   endif
 
@@ -96,7 +96,7 @@
   # It's also required for building OpenCL support.
   ifneq (,$(filter $(DEB_HOST_ARCH), amd64 arm64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 mips64el mipsel powerpc ppc64 ppc64el s390x sparc64))
 	GALLIUM_DRIVERS += ,radeonsi,swrast
-	confflags_GALLIUM += -Dllvm=true
+	confflags_GALLIUM += -Dllvm=enabled
 	confflags_GALLIUM += -Dgallium-opencl=icd
 	confflags_OSMESA = -Dosmesa=gallium
 
@@ -106,7 +106,7 @@
 	endif
   else
 	DRI_DRIVERS += ,swrast
-	confflags_GALLIUM += -Dllvm=false
+	confflags_GALLIUM += -Dllvm=disabled
 	confflags_OSMESA = -Dosmesa=classic
   endif
 
@@ -117,18 +117,18 @@
   endif
 
 	confflags_DIRECT_RENDERING = -Dglx-direct=true
-	confflags_GBM = -Dgbm=true
+	confflags_GBM = -Dgbm=enabled
 	confflags_GALLIUM += -Dgallium-extra-hud=true
-	confflags_GALLIUM += -Dgallium-vdpau=true
-	confflags_GALLIUM += -Dlmsensors=true
+	confflags_GALLIUM += -Dgallium-vdpau=enabled
+	confflags_GALLIUM += -Dlmsensors=enabled
 
   ifeq (,$(filter pkg.mesa.nolibva,$(DEB_BUILD_PROFILES)))
-confflags_GALLIUM += -Dgallium-va=true
+confflags_GALLIUM += -Dgallium-va=enabled
   endif
 endif
 
 confflags_EGL = -Dplatforms="$(EGL_PLATFORMS)"
-confflags_GLES = -Dgles1=false -Dgles2=true
+confflags_GLES = -Dgles1=disabled -Dgles2=enabled
 confflags_GALLIUM += -Dgallium-drivers="$(GALLIUM_DRIVERS)"
 
 confflags += \
@@ -137,8 +137,8 @@
 	-Ddri-search-path='/usr/lib/$(DEB_HOST_MULTIARCH)/dri:\{ORIGIN}/dri:/usr/lib/dri' \
 	-Dvulkan-drivers="$(VULKAN_DRIVERS)" \
 	-Dglvnd=true \
-	-Dshared-glapi=true \
-	-Dgallium-xvmc=false \
+	-Dshared-glapi=enabled \
+	-Dgallium-xvmc=disabled \
 	-Dgallium-omx=disabled \
 	-Db_ndebug=true \
 	-Dbuild-tests=true \

Bug#973562: wordpress: Wordpress 5.5.2 security release

[Craig Small]

Hi Seb,
  Sure are planning on doing that. I'll be using tracking the 5.0.x branch
from upstream, as discussed last time. Thanks to Utkarsh I've got all the
CVEs and descriptions right in front of me!

Hi Utkarsh, I've got Sid uploading now and will start on Buster in a moment.

 - Craig


On Mon, 2 Nov 2020 at 22:52, Sébastien Delafond  wrote:

> On 02/11 08:01, Craig Small wrote:
> > Wordpress versions less than 5.5.2 have the following security
> > vulnerabilities:
> >
> > CVE-2020-28039: Protected meta that could lead to arbitrary file
> deletion.
> > CVE-2020-28035: XML-RPC privilege escalation.
> > CVE-2020-28036: XML-RPC privilege escalation.
> > CVE-2020-28032: Hardening deserialization requests.
> > CVE-2020-28037: DoS attack could lead to RCE.
> > CVE-2020-28038: Stored XSS in post slugs.
> > CVE-2020-28033: Disable spam embeds from disabled sites on a multisite
> network.
> > CVE-2020-28034: Cross-Site Scripting (XSS) via global variables.
> > CVE-2020-28040: CSRF attacks that change a theme's background image.
>
> Hi Craig,
>
> are you planning on backporting the fixes for those on top of buster's
> 5.0.10+dfsg1-0+deb10u1?
>
> Cheers,
>
> --
> Seb
>

Bug#973562: wordpress: Wordpress 5.5.2 security release

[Utkarsh Gupta]

Hi Craig, Seb, Salvatore,

On Mon, 02 Nov 2020 08:01:44 +1100 Craig Small  wrote:
> Debian LTS have released 4.7.19 which fixes this already.

Yep, I have already bumped the version and fixed these CVEs in stretch LTS.

Please let me know in case I can help with any of the other updates?
I don't mean to interfere, of course, but will be happy to prepare an
update for buster or sid, if you need me to! :)


- u

Bug#921178: Re: Bug#940914: uno-libs3: Segfault on launch in cppu::_copyConstructAnyFromData

[Rene Engelhard]

Hi,

Am 03.11.20 um 06:35 schrieb Rene Engelhard:
>> As for reproduction, I believe the easiest is to grab the Debian live
>> CD image and run it in qemu -kvm, and it will reproduce. It does for
>> me. If you can't, please let me know.
> Ah, Live?
>
> Does it only happen in Live and not in "real" systems?
>
> Will try

Just works fine on debian-live-10.6.0-amd64-gnome.iso


Regards,


Rene

Bug#921178: Re: Bug#940914: uno-libs3: Segfault on launch in cppu::_copyConstructAnyFromData

[Rene Engelhard]

Hi,

Am 02.11.20 um 23:30 schrieb Witold Baryluk:
> I did provide stack traces for example in February 2019.
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921178
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940914

True, after which I said I simply can't reproduce it.

> There was zero response from the maintainer, i.e. what other
> information is required.

That is demonstratablly completely untrue.

I did reply to the bug, didn't I? And tagged it + unreproducible.


What is needed: Obviously telling circumstances when it happens.

Backtraces are good, but to make upstream debug it one probably needs to
tell them when it might happen, too

(and to check whether it does not happen anymore.)


And that is totally unclear.

> As for reproduction, I believe the easiest is to grab the Debian live
> CD image and run it in qemu -kvm, and it will reproduce. It does for
> me. If you can't, please let me know.

Ah, Live?

Does it only happen in Live and not in "real" systems?

Will try


Regards,


Rene

Bug#973670: vim-athena: Vim Athena - E236: Font Unifont is not fixed width

[DieSpinne]

Package: vim-athena
Version: 2:8.1.0875-5
Severity: normal

Dear Maintainer,

If I try to set GNU Unifont as my Gvim's font I get errors. Attempt:

:set gfn=-*-unifont-*-*-*-*-*-*-*-*-c-*-*-*

Errors raised:

E236: Font "-*-unifont-*-*-*-*-*-*-*-*-c-*-*-*" is not fixed-width
E596: Invalid font(s): gfn=-*-unifont-*-*-*-*-*-*-*-*-c-*-*-*

Note that GNU Unifont is a fixed width font, as indicated by the "c" in the 
spacing element.
There is no error with "-*-terminus-*-*-*-*-*-*-*-*-c-*-*-*", on the other hand.


-- Package-specific info:

--- real paths of main Vim binaries ---
/usr/bin/vi is /usr/bin/vim.athena
/usr/bin/vim is /usr/bin/vim.athena
/usr/bin/gvim is /usr/bin/vim.athena

-- System Information:
Debian Release: 10.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-12-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages vim-athena depends on:
ii  libacl1 2.2.53-4
ii  libc6   2.28-10
ii  libgpm2 1.20.7-5
ii  libice6 2:1.0.9-2
ii  liblua5.2-0 5.2.4-1.1+b2
ii  libperl5.28 5.28.1-6+deb10u1
ii  libpython3.73.7.3-2+deb10u2
ii  libruby2.5  2.5.5-3+deb10u2
ii  libselinux1 2.8-1+b1
ii  libsm6  2:1.2.3-1
ii  libtcl8.6   8.6.9+dfsg-2
ii  libtinfo6   6.1+20181013-2+deb10u2
ii  libx11-62:1.6.7-1+deb10u1
ii  libxaw7 2:1.0.13-1+b2
ii  libxmu6 2:1.1.2-2+b3
ii  libxpm4 1:3.5.12-1
ii  libxt6  1:1.1.5-1+b3
ii  vim-common  2:8.1.0875-5
ii  vim-gui-common  2:8.1.0875-5
ii  vim-runtime 2:8.1.0875-5

vim-athena recommends no packages.

Versions of packages vim-athena suggests:
pn  cscope   
pn  vim-doc  

-- no debconf information

Bug#972736: Mesa 20.2.1 fails to build on x32 (debian\rules issue)

[Stuart Young]

Patch for debian/rules attached to resolve this bug.

Note: By just checking if the variable is empty first, the patch is
non-specific to x32. It covers the x32 build issue, but will also avoid
such issues for any platform that AMD vulkan drivers aren't built on, but
that can support intel vulkan drivers.

-- 
Stuart Young (aka Cefiar)
--- a/debian/rules	2020-11-03 15:11:24.262177791 +1100
+++ b/debian/rules	2020-11-03 15:20:36.960909848 +1100
@@ -75,7 +75,12 @@
 		GALLIUM_DRIVERS += ,svga,zink
 		# svga needs xa state tracker
 		confflags_GALLIUM += -Dgallium-xa=true
-		VULKAN_DRIVERS += ,intel
+		# VULKAN_DRIVERS var may be empty
+		ifeq ($(strip $(VULKAN_DRIVERS)),)
+			VULKAN_DRIVERS = intel
+		else
+			VULKAN_DRIVERS += ,intel
+		endif
 	endif
 
 	# Non-Linux ports also lack *_CLOEXEC and epoll, so wayland isn't ready yet:

Bug#973674: buster-pu: package mdadm/4.1-8

[Felix Lechner]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Hi,

The mdadm version in buster suffers from Bug#960132, which a reporter assessed
at the serious level. It was fixed version 4.1-6, but the version 4.1-8 that is
currently in testing includes many new translations and is probably a better
candidate.

I believe it is my responsibility per section 3.1.2 of the Developer's
Reference to bring this matter to your attention.

Thanks for your hard work on maintaining the stable release!

Kind regards
Felix Lechner


-- System Information:
Debian Release: 10.6
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf

Kernel: Linux 5.8.0-0.bpo.2-amd64 (SMP w/8 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 /usr/bin/dash

Bug#972246: numba, python3.9, dolfinx

[Rebecca N. Palmer]

Control: affects -1 + pynpoint python-loompy umap-learn
Control: affects -1 + dolfinx python-numpy-groupies

As this bug cannot immediately be fixed, numba may be removed from 
testing to unblock the python3.9 transition (#966426).


(If any of the failed tests are silently wrong answers, please do *not* 
upload a numba version that "fixes" this by ignoring the tests without 
discussion.)


pandas will drop its python3-numba build/autopkgtest-dependency 
(#973589).  Other reverse dependencies that can do so (dolfinx??) should 
do the same if they wish to stay in testing.

Bug#973673: Mesa FTBFS due to build dep on hurd

[Stuart Young]

Package: mesa
Version: 20.2.1-1

Since forever (ie: the 9 yrs of salsa history I could go back through with
git blame), libdrm-dev has been marked not to be a build dep on hurd for
mesa.

eg: From debian/control in 20.2.1-1:
 libdrm-dev (>= 2.4.101) [!hurd-any]

Changes to upstream mesa's surfaceless EGL now basically require libdrm-dev.

>From meson.build in 20.2.1 @ lines 337 -> 343:

if _platforms.contains('surfaceless')  warning('Platform `surfaceless`
is now always selected; setting this option will be an error in Mesa
20.3')endifif _platforms.contains('drm')  warning('Platform `drm` is
now automatically selected; setting this option will be an error in
Mesa 20.3')endif

FWIW: Looks like these changes were made upstream about 3 months ago.

Relaxing the restriction on libdrm-dev actually allows the package to
build, and libdrm is being built already on hurd.

Another way I that may work would be to disable EGL in debian/rules, but
not sure if that's a suitable option?

Note: I can't actually test anything further though as I can't currently
get either mesa 18.3.6 or 20.2.1 to work with qemu passthru on my machine.

-- 
Stuart Young (aka Cefiar)

Bug#973672: transition: re2

[Stefano Rivera]

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

Public ABI Breakage:

The implementation of RE2::Arg was changed from preprocessor macros to
C++ templates. It remains API-compatible, though.

Reverse Dependencies:

$ grep ^Status: *.build
chromium_amd64.build:Status: successful
clickhouse_amd64.build:Status: attempted
dnsdist_amd64.build:Status: successful
effcee_amd64.build:Status: successful
libphonenumber_amd64.build:Status: successful
libpog_amd64.build:Status: successful
libre-engine-re2-perl_amd64.build:Status: successful
node-re2_amd64.build:Status: successful
qtwebengine-opensource-src_amd64.build:Status: successful
re2_20201101+dfsg-1_amd64.build:Status: successful
re2_20201101+dfsg-1_i386.build:Status: successful
ruby-re2_amd64.build:Status: successful

clickhouse FTBFS (#966439) is caused by GCC 10 and unrelated.

Ben file:

title = "re2";
is_affected = .depends ~ "libre2-8" | .depends ~ "libre2-9";
is_good = .depends ~ "libre2-9";
is_bad = .depends ~ "libre2-8";

The automatically generated ben files are usually correct.

SR

Bug#972246: numba, python3.9, dolfinx

[Drew Parsons]

On 2020-11-03 07:33, Rebecca N. Palmer wrote:


As this bug cannot immediately be fixed, numba may be removed from
testing to unblock the python3.9 transition (#966426).

...

pandas will drop its python3-numba build/autopkgtest-dependency
(#973589).  Other reverse dependencies that can do so (dolfinx??)
should do the same if they wish to stay in testing.


Thanks Rebecca, I'll keep watch for dolfinx.

Drew

Bug#968862: remove people.*.html now?

[Thomas Lange]

Hi Laura,

you've wrote

> ## This page is redirected to by qa.d.o/developer.php?all=1
> I have no idea if the page is linked in other places and/or the info is
> valuable for the QA team or others.

We got no feedback since two months and
I cannot find how qa.d.o/developer.php?all=1 is generated on the page
qa.d.o/developer.php. We also have very few accesses to the people
pages (about 50) in the logs. I think the page people.html is not used.
IMO we can remove the people list on www.d.o. If you're OK with this,
I will do it.

I also wonder why the people.*.html file were generated in september.
-- 
regards Thomas

Bug#973671: do not depend on runit-init

[Jamie Heilman]

Package: socklog
Version: 2.1.0+repack-2
Severity: important

socklog is now uninstallable on systems that don't use runit-init
which makes no sense.  This program works without runit-init just
fine, there's no good reason for a hard dependency on runit-init.

-- 
Jamie Heilman http://audible.transient.net/~jamie/

Bug#973623:

[Michael Hudson-Doyle]

I think this is a gold bug, and even better I think it is a gold bug that
was fixed already, in this commit from a few weeks back:

commit fa40fbe484954c560ab1c0ff4bc1b2eeb1511344
Author: Alan Modra 
Date:   Fri Oct 9 16:56:33 2020 +1030

[GOLD] Power10 segv due to wild r2

Calling non-pcrel functions from pcrel code requires a stub to set up
r2.  Gold created the stub, but an "optimisation" made the stub jump
to the function local entry, ie. r2 was not initialised.

This patch fixes that long branch stub problem, and another that might
occur for plt call stubs to local functions.

bfd/
* elf64-ppc.c (write_plt_relocs_for_local_syms): Don't do local
entry offset optimisation.
gold/
* powerpc.cc (Powerpc_relobj::do_relocate_sections): Don't do
local entry offset optimisation for lplt_section.
(Target_powerpc::Branch_info::make_stub): Don't add local
entry offset to long branch dest passed to
add_long_branch_entry.  Do pass st_other bits.
(Stub_table::Branch_stub_ent): Add "other_" field.
(Stub_table::add_long_branch_entry): Add "other" param, and
save.
(Stub_table::branch_stub_size): Adjust long branch offset.
(Stub_table::do_write): Likewise.
(Target_powerpc::Relocate::relocate): Likewise.

In particular, it's this bit:

(Target_powerpc::Branch_info::make_stub): Don't add local
entry offset to long branch dest passed to
add_long_branch_entry.  Do pass st_other bits.

Some background, if anyone cares:

Most functions on ppc64 have two entry points, a global and local entry
point. The global entry point is the one that is called from other shared
objects, derives the "module TOC pointer" from r12 (the abi mandates that
calls via a function pointer must have that pointer in r12), and stores it
in r2. The local entry point assumes that r2 is already set up (and does
not care about what is in r12), so most local calls look like this:

103fa688:   21 91 c0 4b bl  100037a8 <_init+0x8>

(this is from __libc_csu_init from a trivial haskell executable which does
not crash). But! the displacement field for the bl instruction in the ppc64
ISA is "only" 26 bits. When the target function is too far away, the linker
generates a stub, like this:

(gdb) disassemble 0x14dcb998
Dump of assembler code for function 0001.long_branch.10004b48:
   0x14dcb990 <+0>: addis   r12,r2,-1
   0x14dcb994 <+4>: ld  r12,32216(r12)
   0x14dcb998 <+8>: mtctr   r12
   0x14dcb99c <+12>: bctr

This derives the address of the target function from r2, puts it in r12 per
abi rules and calls it. But the call to this stub in __libc_csu_init from a
broken haskell executable looks like this:

   0x14dc8b08 <+72>: bl  0x14dcb998
<0001.long_branch.10004b48+8>

i.e. it's jumping into the middle of the stub, and so jumps straight to
r12, which contains the address of __libc_csu_init itself at the moment --
and so we just recurse infinitely until we crash.

Bug#958174: hdf5: please add the hdf5plugins

[Gilles Filippini]

Gilles Filippini a écrit le 24/04/2020 à 10:03 :
> picca a écrit le 22/04/2020 à 16:07 :
>> I found also this link with all the filter available around hdf5.
>> so I tought that the hdfgroup would provide a tar.gz with all of them
>> pre packaged in source forme.
>>
>> since you are in charge of the hdf5 package, I tought that you have a
>> privilegiate contact with them.
>>
>> https://portal.hdfgroup.org/display/support/HDF5+Plugins
> Not so privileged, but I've asked them anyway. Waiting for the answer.

Here it is (I forgot to forward it):
> I received a reply regarding the hdf5plugin software.  The issue is that
> the source code is not in a state where any user can build it as is.
> Right now the developer has to make certain changes in order for it
> to build.
> 
> We do plan to make it available from the web pages once it has been
> cleaned up. 

Best,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#973669: ksh: ignores tracked aliases during execution

[Benjamin Barenblat]

Package: ksh
Version: 93u+20120801-3.4+deb10u1
Severity: normal
Tags: upstream

ksh doesn’t pay attention to tracked aliases during execution – it
always does a PATH search:

$ strace -e signal=none -P /usr/local/bin/ls -P /usr/bin/ls -P /bin/ls ksh 
+E
$ ls -a
stat("/usr/local/bin/ls", 0x7ffde8d749c0) = -1 ENOENT (No such file or 
directory)
stat("/usr/bin/ls", 0x7ffde8d749c0) = -1 ENOENT (No such file or 
directory)
stat("/bin/ls", {st_mode=S_IFREG|0755, st_size=138856, ...}) = 0
lstat("/bin/ls", {st_mode=S_IFREG|0755, st_size=138856, ...}) = 0
.  ..
$ whence -a ls
ls is a tracked alias for /bin/ls
$ ls -a
stat("/usr/local/bin/ls", 0x7ffde8d749c0) = -1 ENOENT (No such file or 
directory)
stat("/usr/bin/ls", 0x7ffde8d749c0) = -1 ENOENT (No such file or 
directory)
stat("/bin/ls", {st_mode=S_IFREG|0755, st_size=138856, ...}) = 0
lstat("/bin/ls", {st_mode=S_IFREG|0755, st_size=138856, ...}) = 0
.  ..

This is inefficient. It’s also surprising, given that tracked aliases
were originally intended to avoid PATH lookups in cases like this.

This appears to have been first noticed in 2011 by Siddhesh Poyarekar.
marc.info has mangled the thread a bit, but I think it’s


https://marc.info/?i=AANLkTinva-vek-y4CrNPdMic9b_HaFMmKVv=+3tnh...@mail.gmail.com
└ https://marc.info/?i=201102161622.p1ggmyvv022...@penguin.research.att.com
  ├ 
https://marc.info/?i=AANLkTi=ktorzlncfmck16yxackrd6rkljv5ywszfc...@mail.gmail.com
  │ ├ 
https://marc.info/?i=aanlktikiufzexcrxxkx8ckbgm2-tbwg6f1r2+rotw...@mail.gmail.com
  │ └ https://marc.info/?i=rca1529.4d5d6c3...@rightcore.com
  └ https://marc.info/?i=20110307172636.34716...@zaphod.usersys.redhat.com

-- System Information:
Debian Release: 10.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Versions of packages ksh depends on:
ii  binfmt-support  2.2.0-2
ii  libc6   2.28-10

ksh recommends no packages.

ksh suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#973455: keymap dz(la) not supported?

[Holger Wansing]

Hi,

Holger Wansing  wrote:
> Hi,
> 
> Aurelien Jarno  wrote:
> > > > Yes, that's exactly because UTF-8 is the default for years already that 
> > > > the
> > > > Kabylian locale is only available as kab_DZ.
> > > 
> > > Ok, thanks for taking the time to confirm, that this seems no issue 
> > > related
> > > to locales/glibc !
> > > With the above explanation it makes sense so far :-)
> > > So, sorry for the noise.
> > 
> > I have just seen you patch to localechooser:
> > 
> > https://salsa.debian.org/installer-team/localechooser/-/commit/e7c432b8e7579511ff24ca554940b23cd0a9d482#97d66a6f96fa0a78b8cc86e86b52a0144da74883_54_53
> > 
> > I think the locale entry is wrong, as discussed above, it should be
> > kab_DZ instead of kab_DZ.UTF-8. Just like then entries around are ks_IN
> > or km_KH.
> 
> Ah, ok. Thanks for the pointer, I will give that a try.

That does not change anything, sadly.
I would change that anyway (later), to make it at least consistent.


Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#973668: Please update metadata, screenshot etc for Mystiq

[Pablo Mestre]

Hi Otto,

Thanks for the suggestions

I will take care soon.


El 11/2/20 a las 9:12 PM, Otto Kekäläinen escribió:
> Package: mystiq
>
> Hello!
>
> I noticed that there is no screenshot for Mystiq at
> https://screenshots.debian.net/package/mystiq even though it is a
> graphical program.
>
> AppStream also has a couple of warnings about missing metadata:
> https://appstream.debian.org/sid/main/issues/mystiq.html
>
> See also https://tracker.debian.org/pkg/mystiq
>
> If you want to be perfect, also add a icon, labels and badges at
> https://salsa.debian.org/debian/mystiq (compare e.g. to
> https://salsa.debian.org/mariadb-team/mariadb-10.5)

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.

Bug#973668: Please update metadata, screenshot etc for Mystiq

[Otto Kekäläinen]

Package: mystiq

Hello!

I noticed that there is no screenshot for Mystiq at
https://screenshots.debian.net/package/mystiq even though it is a
graphical program.

AppStream also has a couple of warnings about missing metadata:
https://appstream.debian.org/sid/main/issues/mystiq.html

See also https://tracker.debian.org/pkg/mystiq

If you want to be perfect, also add a icon, labels and badges at
https://salsa.debian.org/debian/mystiq (compare e.g. to
https://salsa.debian.org/mariadb-team/mariadb-10.5)

Bug#875306: python-debian: include a type for buildinfo files

[Stuart Prescott]

Hi Chris

On Tuesday, 3 November 2020 00:07:03 AEDT Chris Lamb wrote:
> Hi Stuart,
> 
> > > Glancing at the parsed data structures, it would seem like the code is
> > > collapsing duplicate environment keys in the returned value of
> > > get_environment() as well as throw away the original ordering.
> > 
> > It is deliberate, although inconsistent as you note. I'm happy to be told
> > me reasoning is not sound and that different structures would be better
>
> No, I was mostly just checking; you've clearly thought this through. I
> think your various solutions are more than adequate, especially as we
> don't really define anywhere what happens if any of our fields contain
> duplicates anyway.

All good :)

I'll get this merged and released soonish. Hopefully people will start using 
this class, thinking about more things that it could do, reporting bugs and 
offering patches :)

regards
Stuart

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#973664: BUG: proftpd-basic packaged with broken proftpd.conf, fresh install fails to start

[Hilmar Preuße]

Control: tags -1 + pending

Am 02.11.2020 um 23:49 teilte VDRU VDRU mit:

Hi,

Commenting out the "IdentLookups" line allows proftpd to start and 
connections to work. Please let me know if any further info is

needed.


This has been solved in git [1] already. Tag the bug as pending.

Hilmar

[1] 
https://salsa.debian.org/debian-proftpd-team/proftpd/-/commit/1069aff89a7feacb57830febc006c009fcfd3d22

--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#973667: Directory List /.../.../.../... titles puts "meat" too far to the right

[積丹尼 Dan Jacobson]

X-Debbugs-Cc: yama...@jpl.org
Package: w3m-el-snapshot
Version: 1.4.632+0.20201021.0552.a4edf91-1

Let's say in emacs-w3m we are browsing the directory
file:///home/jidanni/jidanni.org/geo/antipodes/programs/

Well, perhaps the buffer name/title should be

   programs Directory list,

or

   programs Directory list (/home/jidanni/jidanni.org/geo/antipodes/programs/),

instead of

   Directory list of /home/jidanni/jidanni.org/geo/antipodes/programs/

because no matter if in list-buffers,

   File Edit Options Buffers Tools Buffer-Menu Help
   CRM Buffer Size Mode File
   .%  Directory list of /... 6650 w3m  Directory list of 
/home/jidann
%  *GNU Emacs* 964 Fundamental
   *scratch*   145 Lisp Interaction
%* *Messages* 1108 Messages
%* *Completions*   204 Completion List

or the buffer title itself,

   Directory list...

the current way pushes the "meat" of the name too far to the right to be
dealt with properly.

Bug#971415: transition: ocaml

[Sebastian Ramacher]

Hi

On 2020-11-02 19:18:45 +0100, Paul Gevers wrote:
> HI Stéphane,
> 
> On 02-11-2020 16:56, Stéphane Glondu wrote:
> >> autopkgtest for ocaml-cairo2/0.6.1+dfsg-5: amd64: Regression ♻ (reference 
> >> ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), 
> >> i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ (reference ♻)
> > 
> > However, I don't understand why it complains about
> > ocaml-cairo2/0.6.1+dfsg-5 whereas version 0.6.1+dfsg-6 is fixed. Does
> > something need to be done?
> 
> Your symptoms describe a missing *versioned* Depends/Breaks or test
> dependency. The migration software tries run tests with the minimum
> changes. So, if nothing makes sure that the version from unstable is
> needed, it will run with as much packages as possible from testing. What
> we see in the logs is that it installs the test suite from testing.
> Then, the test dependencies are installed and apt-get reports that it
> can't install the required packages. It then falls back to enable
> everything from unstable and then installation is possible.
> 
> Do you confirm that the issue is only in the test? I think we can ignore
> this issue then (or better, trigger the test manually with ocaml-cairo2
> from unstable. With the description above, do you understand why the
> relations in the packages don't teach our migration software what to do?

The test fails because it tries to build the examples contained in the
source package. The version in testing, 0.6.1+dfsg-5, fails to build
with ocaml 4.11.1, so that's expected. The issue was fixed in
0.6.1+dfsg-6.

Since Depends and Breaks do not affect source packages, I don't think
this is fixable in any of the involved packages other than by fixing the
FTFBS bug. I think this issue can be ignored and I will add a hint.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#973666: Cursor left at top when browsing directories

[積丹尼 Dan Jacobson]

X-Debbugs-Cc: yama...@jpl.org
Package: w3m-el-snapshot
Version: 1.4.632+0.20201021.0552.a4edf91-1

$ w3m file:///home/jidanni/jidanni.org/geo/antipodes/programs/
puts the cursor in the right spot.

But in emacs-w3m, the cursor is left way at the top!

Location: file:///home/jidanni/jidanni.org/geo/antipodes/programs/
===>Directory list of /home/jidanni/jidanni.org/geo/antipodes/programs/


/|
+-bin|
+-boot   |
+-cf |
+-dev|
+-etc|
o-home   |
| +-dyy  |
| o-jidanni  |
| | +-.android   |
| | +-.aptitude  |
| | +-.backups   |
| | +-.cache |
| | +-.chewing   |
| | +-.config|
| | +-.dbus  |
| | +-.emacs.d   |
| | +-.emacs_|
| | +-.gconf |
| | +-.gdal  |...

Still miles above where it should be,

| | | o-geo  |
| | | | o-antipodes  |
| | | | | +-images   |
===>programs 
|/home/jidanni/jidanni.org/geo/antipodes/programs/
| | | | +-diaoyutai  |[DIR]  4096 Oct 12 21:37 ../

Bug#973664: BUG: proftpd-basic packaged with broken proftpd.conf, fresh install fails to start

[VDRU VDRU]

Package: proftpd-basic
Version: 1.3.7a-1

Clean install of Debian Testing, upgraded to Debian Unstable.
Installed proftpd-basic, tried connecting, got connection refused.

$ sudo service proftpd status
● proftpd.service - LSB: Starts ProFTPD daemon
 Loaded: loaded (/etc/init.d/proftpd; generated)
 Active: failed (Result: exit-code) since Mon 2020-11-02 14:21:43
PST; 12min ago
   Docs: man:systemd-sysv-generator(8)
Process: 5204 ExecStart=/etc/init.d/proftpd start (code=exited,
status=1/FAILURE)

Nov 02 14:21:43 test systemd[1]: Starting LSB: Starts ProFTPD daemon...
Nov 02 14:21:43 test proftpd[5204]: Starting ftp server: proftpd
Nov 02 14:21:43 test proftpd[5211]: 2020-11-02 14:21:43,401 test
proftpd[5211]: fatal: unknown configuration directive 'IdentLookups'
on line 13 of '/etc/proftpd/proftpd.conf'
Nov 02 14:21:43 test proftpd[5212]:  failed!
Nov 02 14:21:43 test systemd[1]: proftpd.service: Control process
exited, code=exited, status=1/FAILURE
Nov 02 14:21:43 test systemd[1]: proftpd.service: Failed with result
'exit-code'.
Nov 02 14:21:43 test systemd[1]: Failed to start LSB: Starts ProFTPD daemon.

Commenting out the "IdentLookups" line allows proftpd to start and
connections to work. Please let me know if any further info is needed.

Linux test 5.9.0-1-686-pae #1 SMP Debian 5.9.1-1 (2020-10-17) i686 GNU/Linux
/lib/i386-linux-gnu/libc.so.6 -> libc-2.31.so

Bug#973644: mes should be Architecture: amd64 armel armhf i386

[Adrian Bunk]

On Mon, Nov 02, 2020 at 01:56:03PM -0800, Vagrant Cascadian wrote:
> On 2020-11-02, Adrian Bunk wrote:
> > Source: mes
> > Version: 0.22-4
> > Severity: important
> > Tags: ftbfs
> >
> > "amd64 armel armhf i386" are the architectures supported upstream
> > (32bit arm needs some files that are in upsteam but missing in the
> >  0.22 release tarball).
> 
> There is work on adding more architectures in mes upstream (e.g. arm,
> arm64, FreeBSD, Hurd, riscv64)...
> 
> My understanding was in Debian to not pre-emptively restrict
> architectures...

It is not pre-emptively when upstream errors out stating an architecture 
is not supported.

> I have gotten bugs on other packages for adding architecture
> restrictions before even though it FTBFS on those architecture
> before.

It also depends on why it does FTBFS.

When software is amd64-only there is no point wasting porter time for
looking at the FTBFS on other architectures.

For FTBFS caused by bugs you are right that architecture restrictions
should not be done automatically only because a package does FTBFS.

> Having architecture restrictions by default requires porters to get a
> sourceful upload to enable building that package (or maintaining a
> fork).
>...

How do you enable an architecture without a sourceful upload when 
upstream errors out?

It is relatively rare that software needs porting to every single 
architecture, the normal case is software written in a higher language
like C expected to run everywhere without porting.

> live well,
>   vagrant

cu
Adrian

Bug#921178: Re: Bug#940914: uno-libs3: Segfault on launch in cppu::_copyConstructAnyFromData

[Witold Baryluk]

I did provide stack traces for example in February 2019.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921178
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940914

There was zero response from the maintainer, i.e. what other
information is required.

I am attaching a new stack trace to this email just in case.

As for reproduction, I believe the easiest is to grab the Debian live
CD image and run it in qemu -kvm, and it will reproduce. It does for
me. If you can't, please let me know.

I appreciate your help Rene.

Regards,
Witold
[2062261.823403] audit: type=1400 audit(1604356080.583:1375): 
apparmor="ALLOWED" operation="open" info="Failed name lookup - disconnected 
path" error=-13 profile="libreoffice-soffice" name="rw/usr/share/drirc.d" 
pid=275558 comm="soffice.bin" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=0
[2062261.824432] audit: type=1400 audit(1604356080.587:1376): 
apparmor="ALLOWED" operation="open" info="Failed name lookup - disconnected 
path" error=-13 profile="libreoffice-soffice" name="rw/usr/share/drirc.d" 
pid=275558 comm="soffice.bin" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=0
[2062261.917652] audit: type=1400 audit(1604356080.679:1377): 
apparmor="ALLOWED" operation="open" info="Failed name lookup - disconnected 
path" error=-13 profile="libreoffice-soffice" name="rw/usr/share/drirc.d" 
pid=275558 comm="soffice.bin" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=0
[2062261.918059] audit: type=1400 audit(1604356080.679:1378): 
apparmor="ALLOWED" operation="open" info="Failed name lookup - disconnected 
path" error=-13 profile="libreoffice-soffice" name="rw/usr/share/drirc.d" 
pid=275558 comm="soffice.bin" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=0
[2062261.918601] audit: type=1400 audit(1604356080.679:1379): 
apparmor="ALLOWED" operation="open" info="Failed name lookup - disconnected 
path" error=-13 profile="libreoffice-soffice" name="rw/usr/share/drirc.d" 
pid=275558 comm="soffice.bin" requested_mask="r" denied_mask="r" fsuid=1000 
ouid=0
[2062261.918729] audit: type=1400 audit(1604356080.679:1380): 
apparmor="ALLOWED" operation="open" profile="libreoffice-soffice" 
name="/usr/share/libdrm/amdgpu.ids" pid=275558 comm="soffice.bin" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[2062262.548519] audit: type=1400 audit(1604356081.311:1381): 
apparmor="ALLOWED" operation="open" info="Failed name lookup - disconnected 
path" error=-13 profile="libreoffice-soffice" 
name="rw/home/user/.config/libreoffice/4/user/extensions" pid=275527 
comm="soffice.bin" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
[2062262.549217] audit: type=1400 audit(1604356081.311:1382): 
apparmor="ALLOWED" operation="open" info="Failed name lookup - disconnected 
path" error=-13 profile="libreoffice-soffice" 
name="rw/usr/lib/libreoffice/program/services" pid=275527 comm="soffice.bin" 
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
warning: Currently logging to gdbtrace.log.  Turn the logging off and on to make the new setting effective.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Detaching after fork from child process 275558]
[New Thread 0x7fb599ea0700 (LWP 275599)]

Thread 1 "soffice.bin" received signal SIGSEGV, Segmentation fault.
cppu::_copyConstructAnyFromData (pDestAny=pDestAny@entry=0x56064a0541c8, pSource=0x7ffd7ef0dc40, pType=, pTypeDescr=, acquire=0x7fb5a2afba20 , mapping=0x0) at ./cppu/source/uno/copy.hxx:212
212	./cppu/source/uno/copy.hxx: No such file or directory.
#0  cppu::_copyConstructAnyFromData(_uno_Any*, void*, _typelib_TypeDescriptionReference*, _typelib_TypeDescription*, void (*)(void*), _uno_Mapping*) (pDestAny=pDestAny@entry=0x56064a0541c8, pSource=0x7ffd7ef0dc40, pType=, pTypeDescr=, acquire=0x7fb5a2afba20 , mapping=0x0) at ./cppu/source/uno/copy.hxx:212
#1  0x7fb59f39cc64 in cppu::_copyConstructAny(_uno_Any*, void*, _typelib_TypeDescriptionReference*, _typelib_TypeDescription*, void (*)(void*), _uno_Mapping*) (pDestAny=0x56064a0541c8, pSource=, pSource@entry=0x7ffd7ef0dc40, pType=, pTypeDescr=pTypeDescr@entry=0x0, acquire=acquire@entry=0x7fb5a2afba20 , mapping=mapping@entry=0x0) at ./cppu/source/uno/copy.hxx:289
#2  0x7fb59f39c5b3 in uno_type_any_assign(uno_Any*, void*, typelib_TypeDescriptionReference*, uno_AcquireFunc, uno_ReleaseFunc) (pDest=, pSource=pSource@entry=0x7ffd7ef0dc40, pType=, acquire=acquire@entry=0x7fb5a2afba20 , release=release@entry=0x7fb5a2afba30 ) at ./cppu/source/uno/any.cxx:39
#3  0x7fb5a47860b2 in com::sun::star::uno::operator<<=(com::sun::star::uno::Any&, com::sun::star::beans::NamedValue const&) (value=..., rAny=...) at ./include/com/sun/star/uno/Type.h:155
#4  utl::ConfigManager::acquireTree(utl::ConfigItem const&) (item=...) at ./unotools/source/config/configmgr.cxx:123
#5  0x7fb5a4786c06 in utl::ConfigManager::addConfigItem(utl::ConfigItem&) (this=0x7fb5a61aa900 ::get()::instance>, item=...) at 

Bug#968546: libreoffice-calc: While loading a file, Not all attributes could be read

[Dirk Griesbach]

Hello,

Am Mo, 17. Aug 2020 um 08:54:05 +0200 schrieb frydo bugdeb:

When I load this empty file, or any file, with libreoffice-calc, an error
message appear : Not all attributes could be read (in french : "Certains
attributs n'ont pas pu être lus.")

This error appears on my 32 bit computer, but not on my 64 bit computer, both
up-to-date on debian testing.


I encountered the same problem on 32 bit Debian. However, Libreoffice 
7.0.3 in unstable works fine for me again. Both a freshly created spread 
sheet and an old one open without error.


Regards,
Dirk

Bug#930195: avr-libc: Upstream avr-libc maintainers appear to be MIA; can another source be found?

[Andy Bennett]

Hello again,

Is there an upgraded package that I could try that has the support 
discussed above for the "0-series"?


Thanks!



Best wishes,
@ndy

--
andy...@ashurst.eu.org
http://www.ashurst.eu.org/
0x7EBA75FF

Bug#963630: RFP-ing libaparapi-java due to licensing issues at the moment

[Pierre Gruet]

Control: retitle -1 RFP: libaparapi-java -- framework for executing native Java 
code on the GPU

(this is RFP and not RFS, sorry...)

I am changing the ITP bug to RFP because the wording of the license still
precludes packaging. The blocking part is the last paragraph in ATTRIBUTIONS.md:
it does not seem to be harming when considering packaging aparapi itself, but it
would impose restrictions on other software that might be bundled with it.

We will discuss it with upstream and consider packaging later.

Pierre Gruet

Bug#963630: RFS-ing libaparapi-java due to licensing issues at the moment

[Pierre Gruet]

Control: retitle -1 RFS: libaparapi-java -- framework for executing native Java 
code on the GPU

I am changing the ITP bug to RFS because the wording of the license still
precludes packaging. The blocking part is the last paragraph in ATTRIBUTIONS.md:
it does not seem to be harming when considering packaging aparapi itself, but it
would impose restrictions on other software that might be bundled with it.

We will discuss it with upstream and consider packaging later.

Pierre Gruet

Bug#973644: mes should be Architecture: amd64 armel armhf i386

[Vagrant Cascadian]

On 2020-11-02, Adrian Bunk wrote:
> Source: mes
> Version: 0.22-4
> Severity: important
> Tags: ftbfs
>
> "amd64 armel armhf i386" are the architectures supported upstream
> (32bit arm needs some files that are in upsteam but missing in the
>  0.22 release tarball).

There is work on adding more architectures in mes upstream (e.g. arm,
arm64, FreeBSD, Hurd, riscv64)...

My understanding was in Debian to not pre-emptively restrict
architectures...

I have gotten bugs on other packages for adding architecture
restrictions before even though it FTBFS on those architecture
before.

Having architecture restrictions by default requires porters to get a
sourceful upload to enable building that package (or maintaining a
fork).

I can see the logic of either approach...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#973637: flag debian/watch files that use older versions of the format

[Xavier]

> Hi Jelmer
>
> On Mon, Nov 2, 2020 at 9:57 AM Jelmer Vernooij 
> wrote:
> >
> > It would be great if lintian could flag debian/watch files that
> > didn't use a watch file format version or use an older version
> > (< 4).
>
> Can you just use the existing classification tag
> debian-watch-file-standard [1] [2]? It will give you the version.
>
> Please feel free to close if that tag works for you. Thanks!

Hi all,

1. We could have a "info" lintian tag for version 3, deprecated but
compatible with version 4. But version 2 is really deprecated and it's
not easy to maintain uscan with 4 versions (It took me a lot of hours to
rewrite old uscan to modern Perl-OO).
That's why I'd like to see a "error" tag for version ≤ 2.

2. Since version 3 is compatible with version 4, debian-janitor could
automatically update debian/watch from version 3 to version 4 [1], but
without changing debian/watch when version is ≤ 2 [1] (I think only a
few packages still use version 2 and version < 2 [= no-version] already
generates an error).

3. After bullseye release, I'd like to propose to remove version=2
support from uscan.

Cc to debian-devel for advices if I'm wrong;

NB:
 * Version 2:  4 Feb 2002
 * Version 3: 15 Mar 2005
 * Version 4: 30 Dec 2015

[1]: https://salsa.debian.org/jelmer/debian-janitor/-/issues/144

 8<  end of uscan(1) manpage  8< 
HISTORY AND UPGRADING

This section briefly describes the backwards-incompatible watch file
features which have been added in each watch file version, and the first
version of the devscripts package which understood them.

  Pre-version 2
The watch file syntax was significantly different in those days.
Don't use it.  If you are upgrading from a pre-version 2 watch file,
you are advised to read this manpage and to start from scratch.

  Version 2
devscripts version 2.6.90: The first incarnation of the current
style of watch files.

  Version 3
devscripts version 2.8.12: Introduced the following: correct
handling of regex special characters in the path part,
directory/path pattern matching, version number in several parts,
version number mangling. Later versions have also introduced URL
mangling.

If you are upgrading from version 2, the key incompatibility is if
you have multiple groups in the pattern part; whereas only the first
one would be used in version 2, they will all be used in version 3.
To avoid this behavior, change the non-version-number groups to be
(?:  ... ) instead of a plain (  ...  ) group.

• uscan invokes the custom script as "script --upstream-version
  version ../spkg_version.orig.tar.gz".

• uscan invokes the standard uupdate as "uupdate --no-symlink
  --upstream-version version ../spkg_version.orig.tar.gz".

  Version 4
devscripts version 2.15.10: The first incarnation of watch files
supporting multiple upstream tarballs.

The syntax of the watch file is relaxed to allow more spaces for
readability.

If you have a custom script in place of uupdate, you may also
encounter problems updating from Version 3.

• uscan invokes the custom script as "script --upstream-version
  version".

• uscan invokes the standard uupdate as "uupdate --find
  --upstream-version version".

Restriction for --dehs is lifted by redirecting other output to
STDERR when it is activated.
 >8 

Bug#973663: autopkgtest-build-qemu: supporting armel

[Ryutaroh Matsumoto]

Package: autopkgtest
Version: 5.15
Severity: wishlist
Tags: patch

Dear Maintainer,

There is no standard Debian kernel package for armel architecture,
as the armel hardwares are too diverse.
Maybe because of that, autopkgtest-build-qemu does not support armel.

A bootable armel QEMU testbed can be created by
1. adding armhf as the secondary architecture by dpkg --add-architecture
2. use linux-image-armmp-lpae:armhf or linux-image-armmp:armhf as the kernel.

A suggested patch to autopkgtest-build-qemu for armel support is
attached. As UEFI booting is indispensable with ARM architectures,
such changes are also included in the patch.

Best regards, Ryutaroh Matsumoto


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.9.0-1-arm64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
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 autopkgtest depends on:
ii  apt-utils   2.1.11
ii  libdpkg-perl1.20.5
ii  procps  2:3.3.16-5
ii  python3 3.8.2-3
ii  python3-debian  0.1.38

Versions of packages autopkgtest recommends:
ii  autodep8  0.24

Versions of packages autopkgtest suggests:
ii  lxc   1:4.0.4-5
pn  lxd   
ii  ovmf  2020.08-1
ii  qemu-efi-aarch64  2020.08-1
ii  qemu-efi-arm  2020.08-1
pn  qemu-system   
ii  qemu-utils1:5.1+dfsg-4+b1
pn  schroot   
ii  vmdb2 0.19-1

-- no debconf information
--- /usr/bin/autopkgtest-build-qemu-orig2020-10-31 10:05:36.350588392 
+0900
+++ /usr/bin/autopkgtest-build-qemu 2020-11-03 06:35:38.005181838 +0900
@@ -209,8 +209,11 @@
 ;;
   *)
 case "$architecture" in
+  (armel)
+kernel=linux-image-armmp-lpae:armhf
+;;
   (armhf)
-kernel=linux-image-armmp
+kernel=linux-image-armmp-lpae
 ;;
   (hppa)
 kernel=linux-image-parisc
@@ -235,6 +238,11 @@
 ;;
 esac
 
+if [ "$architecture" = armel ]; then
+second_architecture=armhf
+else
+second_architecture="$architecture"
+fi
 
 if [ "$architecture" = "$(dpkg --print-architecture)" ]; then
 debootstrap_cmd=debootstrap
@@ -252,12 +260,20 @@
   - mkimg: "{{ image }}"
 size: $size
 
-  - mklabel: msdos
+  - mklabel: gpt
 device: "{{ image }}"
 
   - mkpart: primary
+fs-type: fat32
 device: "{{ image }}"
 start: 0%
+end: 200MiB
+tag: efipart
+
+  - mkpart: primary
+fs-type: ext4
+device: "{{ image }}"
+start: 200MiB
 end: 100%
 tag: root
 
@@ -266,21 +282,33 @@
   - mkfs: ext4
 partition: root
 
+  - mkfs: vfat
+partition: efipart
+
   - mount: root
 
   - $debootstrap_cmd: $release
 mirror: $mirror
+components:
+- main
+- contrib
+- non-free
 target: root
 $debootstrap_arch
 
+  - chroot: root
+shell: |
+  dpkg --add-architecture $second_architecture
+
   - apt: install
 packages:
   - $kernel
   - ifupdown
 tag: root
 
-  - grub: bios
+  - grub: uefi
 tag: root
+efi: efipart
 console: serial
 
   - chroot: root
@@ -294,7 +322,10 @@
   - shell: |
   rootdev=\$(ls -1 /dev/mapper/loop* | sort | tail -1)
   uuid=\$(blkid -c /dev/null -o value -s UUID \$rootdev)
-  echo "UUID=\$uuid / ext4 errors=remount-ro 0 1" > \$ROOT/etc/fstab
+  echo "UUID=\$uuid / ext4 
errors=remount-ro,discard,lazytime,commit=3600,nobarrier,strictatime 0 1" > 
\$ROOT/etc/fstab
+  efidev=\$(ls -1 /dev/mapper/loop* | sort | head -1)
+  uuid=\$(blkid -c /dev/null -o value -s UUID \$efidev)
+  echo "UUID=\$uuid /boot/efi vfat rw,discard,lazytime,async 0 2" >> 
\$ROOT/etc/fstab
 root-fs: root
 
   - shell: '$script \$ROOT'

Bug#957062: bygfoot: ftbfs with GCC-10

[Markus Koschany]

Hi Elías,

Am 02.11.20 um 21:48 schrieb Elías Alejandro:

Hi Markus,

On Sun, Nov 1, 2020 at 10:03 AM Markus Koschany  wrote:


Control: tags -1 pending

Dear maintainer,

I've prepared an NMU for bygfoot (versioned as 2.3.2-2.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.


Go ahead with NMU. Thanks.


Thanks. I think it's ok to wait until Friday when the delay is over. 
Everything will happen automatically.


Cheers,

Markus


OpenPGP_0xD9AD14B9513B51E4.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Bug#962790: python-pairix_0.3.7-1_amd64.changes REJECTED

[Andreas Tille]

Hi Sean,

On Sun, Nov 01, 2020 at 12:00:09AM +, Sean Whitton wrote:
> +--+
> |   REJECT reasoning   |
> +--+
> 
> There are copyright holders not given in d/copyright; please use
> 
> grep --color=always -Eir '(copyright|©)' * | less -R
> 
> to find them.

Fixed in new upload.
 
> +--+
> |Other comments|
> +--+
> 
> Given that the source package is python-pairix, shouldn't the examples binary
> package be python-pairix-examples not python3-pairix-examples?

Fixed as well.

Thanks a lot to you and all other members of the ftpmaster team who
managed to tear down the new queue nearly to zero.  Its a **huge lot of
fun** right now to upload packages to new.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#973661:

[Tyler Klein-Rach]

Package: installation-reports

Boot method: 
Image version: 
Date: 

Machine: 
Processor:
Memory:
Partitions: 

Output of lspci -knn (or lspci -nn):

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [ ]
Detect network card:[ ]
Configure network:  [ ]
Detect CD:  [ ]
Load installer modules: [ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:

Bug#973662: autopkgtest-build-qemu: suggesting linux-image-686-pae

[Ryutaroh Matsumoto]

Package: autopkgtest
Version: 5.15
Severity: wishlist
Tags: patch

Dear Maintainer,

This wishlist is in the same spirit as
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973592

When --ram-size 5120 is given to autopkgtest,
linux-image-686 can only use 3GB, while
linux-image-686-pae can use 5 GB.

linux-image-686-pae should enable faster testing of larger packages.
In addition, Debian Jessie also has linux-image-686-pae,
while it does not have linux-image-686 (it has linux-image-586).
A suggested patch to autopkgtest-build-qemu is below.


--- usr/bin/autopkgtest-build-qemu-orig 2020-11-01 17:57:05.974493964 +0900
+++ usr/bin/autopkgtest-build-qemu  2020-11-03 06:04:45.602745803 +0900
@@ -216,14 +216,7 @@
 kernel=linux-image-parisc
 ;;
   (i386)
-case "$release" in
-  (jessie)
-kernel=linux-image-586
-;;
-  (*)
-kernel=linux-image-686
-;;
-esac
+kernel=linux-image-686-pae
 ;;
   (ppc64)
 kernel=linux-image-powerpc64

Best regards, Ryutaroh Matsumoto


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

Kernel: Linux 5.8.0-1-amd64 (SMP w/12 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages autopkgtest depends on:
ii  apt-utils   2.1.11
ii  libdpkg-perl1.20.5
ii  procps  2:3.3.16-5
ii  python3 3.8.2-3
ii  python3-debian  0.1.38

Versions of packages autopkgtest recommends:
ii  autodep8  0.24

Versions of packages autopkgtest suggests:
pn  lxc   
pn  lxd   
ii  ovmf  2020.08-1
ii  qemu-efi-aarch64  2020.08-1
ii  qemu-efi-arm  2020.08-1
ii  qemu-system   1:5.1+dfsg-4+b1
ii  qemu-utils1:5.1+dfsg-4+b1
pn  schroot   
ii  vmdb2 0.19-1

-- no debconf information

Bug#973611: libverto: Please consider switching to libevent

[Sam Hartman]

> "Balint" == Balint Reczey  writes:

Balint> Hi Sam, Thank you for the quick response.
>> That said, I think libverto in Debian should support all the
>> options, and certainly should support libevent.  That won't make
>> things easier for Ubuntu really, if they want to avoid building
>> libverto against libev, but it will let Debian users use libevent
>> if that's what they want.

Balint> In general I agree with offering the choice, but in that
Balint> particular package's case I saw no prior indication of any
Balint> user wanting to use libverto-libevent1 rather than
Balint> libverto-libev1. I see that you maintain krb5, too. What
Balint> advantage do you see in providing libverto-libevent1, too,
Balint> that would make the extra complexity worth it?

So, if you are using libverto, in a particular application, you are
probably happier if your libverto event loop matches up well with your
application event loop.
So if you're using a library like krb5 in an application that uses
libevent or glib, you probably would like libverto to use that event
loop.

(libverto is effectively designed to allow libraries to use an event
loop.)
This doesn't matter in practice because not a lot of people use
libverto.
And because libkrb5 doesn't tend to use libverto much; I seem to recall
it's more a kdc-side thing.

In general in Debian though we tend to turn on all the upstream
compile-time options that a package supports.

Honestly, libverto seems like one too many layers for my taste.
Yeah, it's kind of a PITA to glue too event loops together, but it
actually is possible in the cases that matter, and I kind of wish that
krb5 had just chosen one event loop (pick any one) rather than going and
designing an abstraction for abstracting away the choice of event loop.


So, with my Debian-packages-should-support-upstream options hat on, I
kind of feel like libverto should support all the options as a wishlist
priority.
But I can't say that I think it would make much difference or that it's
where I plan to spend a lot of time.

Bug#973660: thunderbird: FTBFS on s390x in buster

[Adam D. Barratt]

Package: src:thunderbird
Version: 78.3.1-2~deb10u1
Severity: serious
Tags: ftbfs
Control: affects -1 release.debian.org security.debian.org
X-Debbugs-Cc: t...@security.debian.org

Hi,

Since 78.3.1, thunderbird FTBFS on s390x in buster(-security).

The relevant part of the logs appears to be:

make[5]: Entering directory 
'/<>/obj-thunderbird/config/external/icu/data'
mkdir -p '.deps/'
config/external/icu/data/icudata_gas.o
/usr/bin/clang -std=gnu99 -o icudata_gas.o -DNDEBUG=1 -DTRIMMED=1 -fPIC 
-Wa,--noexecstack -include /<>/obj-thunderbird/mozilla-config.h 
-DMOZILLA_CLIENT -g -I/<>/config/external/icu/data 
-I/<>/config/external/icu/data/ '-DICU_DATA_FILE="icudt67b.dat"' 
-DICU_DATA_SYMBOL=icudt67_dat  -c 
/<>/config/external/icu/data/icudata_gas.S
/<>/config/external/icu/data/icudata_gas.S:17:17: error: Could not 
find incbin file 'icudt67b.dat'
.incbin "icudt67b.dat"
^
make[5]: *** [/<>/config/rules.mk:743: icudata_gas.o] Error 1
make[5]: Leaving directory 
'/<>/obj-thunderbird/config/external/icu/data'
make[4]: *** [/<>/config/recurse.mk:74: 
config/external/icu/data/target-objects] Error 2

Regards,

Adam

Bug#973658: ITP: mosdepth -- BAM/CRAM depth calculation biological sequencing

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: mosdepth -- BAM/CRAM depth calculation biological sequencing
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: mosdepth
  Version : 0.3.1
  Upstream Author : Brent Pedersen
* URL : https://github.com/brentp/mosdepth
* License : Expat
  Programming Lang: Python
  Description : BAM/CRAM depth calculation biological sequencing
 Many small reads are produced by high-throughput "next generation"
 sequencing technologies. The final sequence is derived from how
 these reads are overlapping towards a consensus.
 The more reads are covering/confirming parts of a nucleotide seq,
 the higher the confidence is. Too many reads would be indicative
 of e.g. repeats in the genome.
 .
 mosdepth can output:
  *  per-base depth about 2x as fast samtools depth--about 25 minutes
 of CPU time for a 30X genome.
  *  mean per-window depth given a window size--as would be used for
 CNV calling.
  *  the mean per-region given a BED file of regions.
  *  a distribution of proportion of bases covered at or above a given
 threshhold for each chromosome and genome-wide.
  *  quantized output that merges adjacent bases as long as they fall
 in the same coverage bins e.g. (10-20)
  *  threshold output to indicate how many bases in each region are
 covered at the given thresholds.
 when appropriate, the output files are bgzipped and indexed for ease
 of use.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/mosdepth

Bug#973659: qtdeclarative5-dev-tools: qmlcachegen segfaults on hppa

[John David Anglin]

Package: qtdeclarative5-dev-tools
Version: 5.14.2+dfsg-3
Severity: normal

Dear Maintainer,

The qtgraphicaleffects-opensource-src package fails to build on hppa
because qmlcachegen faults with out-of bounds references:

do_page_fault() command='qmlcachegen' type=15 address=0xf98c4020 in 
qmlcachegen[1+c5000]
trap #15: Data TLB miss fault, vm_start = 0xf90c4000, vm_end = 0xf98c4000

do_page_fault() command='qmlcachegen' type=15 address=0xfaed5000 in 
libQt5Core.so.5.15.1[f7f28000+5e6000]
trap #15: Data TLB miss fault, vm_start = 0xfa6d5000, vm_end = 0xfaed5000

do_page_fault() command='qmlcachegen' type=15 address=0xf99b9000 in 
libQt5Core.so.5.15.1[f7f28000+5e6000]
trap #15: Data TLB miss fault, vm_start = 0xf91b9000, vm_end = 0xf99b9000

See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973646
for details regarding the qtgraphicaleffects-opensource-src build.

Regards,
Dave Anglin

-- System Information:
Debian Release: bullseye/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 5.8.18+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages qtdeclarative5-dev-tools depends on:
ii  libc6  2.31-4
ii  libgcc-s4  10.2.0-16
ii  libqt5core5a [qtbase-abi-5-14-2]   5.14.2+dfsg-6
ii  libqt5gui5 5.14.2+dfsg-6
ii  libqt5network5 5.14.2+dfsg-6
ii  libqt5qml5 [qtdeclarative-abi-5-14-2]  5.14.2+dfsg-3
ii  libqt5quick5   5.14.2+dfsg-3
ii  libqt5quicktest5   5.14.2+dfsg-3
ii  libqt5widgets5 5.14.2+dfsg-6
ii  libstdc++6 10.2.0-16
ii  qtchooser  66-2

qtdeclarative5-dev-tools recommends no packages.

qtdeclarative5-dev-tools suggests no packages.

-- no debconf information

Bug#973657: src:rust-onig: autopkgtest uses enormous amount (> 25 GB) of disk space

[Paul Gevers]

Source: rust-onig
Version: 5.0.0-3
Severity: important
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: issue

Dear maintainer,

Your package rust-onig has an autopkgtest, great. However, the
autopkgtest is seriously straining our infrastructure at ci.debian.net.
The package basically isn't able to successfully finish on several of
our architectures. You can see the results e.g. on ppc64el [1].

Most of our ppc64el and arm64 workers have a 40 GB disk, which really
aught to be enough. Please fix your test to not need such enormous
amount of disk, or if you don't want to change your test to reduce the
amount of space needed, at least add a check for the required amount of
disk space and exit 77 (skippable restriction) in case there is not
enough space.

In the past I have blocked the test on arm64 already, I am now doing the
same on ppc64el. I will remove the block once this bug is fixed.

Paul

[1] https://ci.debian.net/user/britney/jobs?package=rust-onig[]=ppc64el






signature.asc
Description: OpenPGP digital signature

Bug#973656: digikam-private-libs wants libkf5akonadicontact5-20.04, but only libkf5akonadicontact5 4:20.08.2-3 is availible

[robert]

Package: digikam-private-libs
Version: 4:6.4.0+dfsg-3+b3
Severity: important
X-Debbugs-Cc: robert.step...@entenhof-im-ried.de

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***
apt install -t experimental digikam
digikam-private-libs : Hängt ab von: libkf5akonadicontact5-20.04 ist aber nicht
installierbar
apt -a list libkf5akonadicontact5
libkf5akonadicontact5/testing,testing,unstable,now 4:20.08.2-3 amd64
[Installiert,automatisch]



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (200, 'unstable'), (50, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages digikam-private-libs depends on:
ii  kio  5.74.0-2
ii  libavcodec58 7:4.3.1-5
ii  libavfilter7 7:4.3.1-5
ii  libavformat587:4.3.1-5
ii  libavutil56  7:4.3.1-5
ii  libc62.31-4
ii  libexiv2-27  0.27.3-3
ii  libexpat12.2.10-1
ii  libgcc-s110.2.0-15
ii  libgl1   1.3.2-1
ii  libgomp1 10.2.0-15
ii  libgphoto2-6 2.5.26-2
ii  libgphoto2-port122.5.26-2
ii  libjpeg62-turbo  1:2.0.5-1.1
ii  libkf5akonadicontact5 [libkf5akonadicontact5-20.08]  4:20.08.2-3
ii  libkf5calendarcore5abi2  5:5.74.0-2
ii  libkf5completion55.74.0-2
ii  libkf5configcore55.74.0-2
ii  libkf5configgui5 5.74.0-2
ii  libkf5configwidgets5 5.74.0-2
ii  libkf5contacts5  5:5.74.0-2
ii  libkf5coreaddons55.74.0-2
ii  libkf5filemetadata3  5.74.0-2
ii  libkf5i18n5  5.74.0-3
ii  libkf5iconthemes55.74.0-2
ii  libkf5kiocore5   5.74.0-2
ii  libkf5kiowidgets55.74.0-2
ii  libkf5notifications5 5.74.0-2
ii  libkf5notifyconfig5  5.74.0-2
ii  libkf5sane5  20.08.0-1
ii  libkf5service-bin5.74.0-2
ii  libkf5service5   5.74.0-2
ii  libkf5solid5 5.74.0-2
ii  libkf5threadweaver5  5.74.0-2
ii  libkf5widgetsaddons5 5.74.0-3
ii  libkf5windowsystem5  5.74.0-2
ii  libkf5xmlgui55.74.0-2
ii  liblcms2-2   2.9-4+b1
ii  liblensfun1  0.3.2-5
ii  liblqr-1-0   0.4.2-2.1
ii  libmagick++-6.q16-8  8:6.9.11.24+dfsg-1+b1
ii  libmagickcore-6.q16-68:6.9.11.24+dfsg-1+b1
ii  libmarblewidget-qt5-28   4:20.08.0-1
ii  libopencv-core4.24.2.0+dfsg-6+b4
ii  libopencv-imgproc4.2 4.2.0+dfsg-6+b4
ii  libopencv-objdetect4.2   4.2.0+dfsg-6+b4
ii  libpng16-16  1.6.37-3
ii  libqt5concurrent55.14.2+dfsg-6
ii  libqt5core5a 5.14.2+dfsg-6
ii  libqt5dbus5  5.14.2+dfsg-6
ii  libqt5gui5   5.14.2+dfsg-6
ii  libqt5network5   5.14.2+dfsg-6
ii  libqt5printsupport5  5.14.2+dfsg-6
ii  libqt5sql5   5.14.2+dfsg-6
ii  libqt5webkit5  

Bug#890657: Closing the bug

[Anton Gladky]

890657 fixed 2.0.1+dfsg1-1
thanks

The newer qcustomplot has a fix for this problem [1].
Thus I am closing this bug.

[1] 
https://salsa.debian.org/science-team/qcustomplot/-/blob/master/qcustomplot.h#L83

Thanks for your contribution!

Best regards

Anton

Bug#973655: buster-pu: package distro-info-data/0.41+deb10u3

[Stefano Rivera]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]

I want to update distro-info-data, so that it knows about the current
Ubuntu development release.

[ Impact ]

Currently on a Buster system:
$ ubuntu-distro-info --devel
ubuntu-distro-info: Distribution data outdated.
Please check for an update for distro-info-data. See 
/usr/share/doc/distro-info-data/README.Debian for details.

With this change:
$ ubuntu-distro-info --devel
hirsute

[ Tests ]

It's just a data package. There are automated tests for correctness.
The data was copied from the version uploaded to unstable.

[ Risks ]

Negligible, it's a new entry in the Ubuntu releases table.

[ Checklist ]

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

[ Changes ]

  * Update data to 0.45:
- Add Ubuntu 21.04, Hirsute Hippo.

[ Other info ]

Last update's bug: #958714

[ Debdiff ]

diff -Nru distro-info-data-0.41+deb10u2/debian/changelog 
distro-info-data-0.41+deb10u3/debian/changelog
--- distro-info-data-0.41+deb10u2/debian/changelog  2020-04-24 
09:24:59.0 -0700
+++ distro-info-data-0.41+deb10u3/debian/changelog  2020-11-02 
12:44:14.0 -0800
@@ -1,3 +1,10 @@
+distro-info-data (0.41+deb10u3) buster; urgency=medium
+
+  * Update data to 0.45:
+- Add Ubuntu 21.04, Hirsute Hippo.
+
+ -- Stefano Rivera   Mon, 02 Nov 2020 12:44:14 -0800
+
 distro-info-data (0.41+deb10u2) buster; urgency=medium
 
   * Update data to 0.44:
diff -Nru distro-info-data-0.41+deb10u2/ubuntu.csv 
distro-info-data-0.41+deb10u3/ubuntu.csv
--- distro-info-data-0.41+deb10u2/ubuntu.csv2020-04-24 09:24:59.0 
-0700
+++ distro-info-data-0.41+deb10u3/ubuntu.csv2020-11-02 12:44:14.0 
-0800
@@ -32,3 +32,4 @@
 19.10,Eoan Ermine,eoan,2019-04-18,2019-10-17,2020-07-17
 20.04 LTS,Focal Fossa,focal,2019-10-17,2020-04-23,2025-04-23
 20.10,Groovy Gorilla,groovy,2020-04-23,2020-10-22,2021-07-22
+21.04,Hirsute Hippo,hirsute,2020-10-22,2021-04-22,2022-01-22

SR

Bug#957062: bygfoot: ftbfs with GCC-10

[Elías Alejandro]

Hi Markus,

On Sun, Nov 1, 2020 at 10:03 AM Markus Koschany  wrote:
>
> Control: tags -1 pending
>
> Dear maintainer,
>
> I've prepared an NMU for bygfoot (versioned as 2.3.2-2.1) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.
>
Go ahead with NMU. Thanks.

Best regards
Elías Alejandro

Bug#973611: libverto: Please consider switching to libevent

[Balint Reczey]

Hi Sam,

Thank you for the quick response.

On Mon, Nov 2, 2020 at 2:46 PM Sam Hartman  wrote:
>
> So, the main reason we're using libev is that upstream krb5 uses libev.
> I think they do because libev is a smaller more self contained code base
> than libevent, and because honestly the KDC isn't normally a performance
> bottleneck, so it doesn't much matter.

Good point, size of code base also matters.

> That said, I think libverto in Debian should support all the options,
> and certainly should support libevent.
> That won't make things easier for Ubuntu really, if they want to avoid
> building libverto against libev, but it will let Debian users use
> libevent if that's what they want.

In general I agree with offering the choice, but in that particular
package's case I saw no prior indication of any user wanting to use
libverto-libevent1 rather than libverto-libev1. I see that you
maintain krb5, too. What advantage do you see in providing
libverto-libevent1, too, that would make the extra complexity worth
it? In fact maintaining the Ubuntu delta would become slightly more
complicated.

Cheers,
Balint

> I'd love a merge proposal that turns on libevent and leaves libev
> present, and will eventually try to get to that myself if you aren't
> interested in submitting that.


--
Balint Reczey
Ubuntu & Debian Developer

Bug#973654: TLS: start_SSL fails to set SSL_verifycn_name

[Martina Ferrari]

Package: amavisd-new
Version: 1:2.11.0-6.1
Severity: important

Hi,

As part of a new server setup, I have installed amavisd-new. Since it is
running in a different host than the MX, I have set up TLS between every part
of the system, but amavis fails to connect back to the MX, with the following
error:

(!!)Upgrading socket to TLS failed (in ssl_upgrade): hostname verification 
failed\n

After some investigation, I found that amavis is not using the IO::Socket::SSL
library correctly. The default (and reasonable) SSL parameters for the client
TLS connection are:

  %smtp_tls_client_options = (
SSL_verifycn_scheme => 'smtp',
  );

When the `$tls_security_level_out` variable is set to 'may' or 'encrypt', the
socket is upgraded to TLS using the `start_SSL` method and the options set by
the user but without any way for the library to determine the hostname of the
server, and therefore its identity can't be verified.

The documentation for the `SSL_verifycn_name` option of the `start_SSL` method
states (https://metacpan.org/pod/IO::Socket::SSL#SSL_verifycn_name):

  SSL_verifycn_name

Set the name which is used in verification of hostname. If
SSL_verifycn_scheme is set and no SSL_verifycn_name is given it will try to
use SSL_hostname or PeerHost and PeerAddr settings and fail if no name can
be determined. If SSL_verifycn_scheme is not set it will use a default
scheme and warn if it cannot determine a hostname, but it will not fail.

Using PeerHost or PeerAddr works only if you create the connection directly
with IO::Socket::SSL->new, if an IO::Socket::INET object is upgraded with
start_SSL the name has to be given in SSL_verifycn_name or SSL_hostname.

The solution for this is pretty simple: `SSL_verifycn_name` has to be set by
the calling function using the same hostname used to connect the TCP socket in
the first place. A workaround is to pass this option manually in the
configuration, but that fails to work if there is more than one SSL target (for
example, different hostnames for `notify_method` and `forward_method`).

-- System Information:
Debian Release: 10.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-9-amd64 (SMP w/1 CPU core)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IE:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages amavisd-new depends on:
ii  adduser  3.118
ii  debconf [debconf-2.0]1.5.71
ii  file 1:5.35-4+deb10u1
ii  init-system-helpers  1.56+nmu1
ii  libarchive-zip-perl  1.64-1
ii  libberkeleydb-perl   0.55-2
ii  libconvert-tnef-perl 0.18-1
ii  libconvert-uulib-perl1:1.5~dfsg-1+b1
pn  libdigest-md5-perl   
ii  libio-stringy-perl   2.111-3
ii  libmail-dkim-perl0.54-1
ii  libmailtools-perl2.18-1
pn  libmime-base64-perl  
ii  libmime-tools-perl   5.509-1
ii  libnet-libidn-perl   0.12.ds-3+b1
ii  libnet-server-perl   2.009-1
ii  libunix-syslog-perl  1.1-3+b1
ii  lsb-base 10.2019051400
ii  pax  1:20190224-1
ii  perl [libtime-hires-perl]5.28.1-6+deb10u1
ii  perl-modules-5.24 [libarchive-tar-perl]  5.24.1-3+deb9u6

Versions of packages amavisd-new recommends:
pn  altermime 
ii  libnet-patricia-perl  1.22-1+b5
ii  ripole0.2.0+20081101.0215-3

Versions of packages amavisd-new suggests:
ii  apt-listchanges  3.19
ii  arj  3.10.22-18
ii  cabextract   1.9-1
pn  clamav   
ii  clamav-daemon0.102.4+dfsg-0+deb10u1
ii  cpio 2.12+dfsg-9
pn  dspam
ii  lhasa0.3.1-3
pn  libauthen-sasl-perl  
ii  libdbi-perl  1.642-1+deb10u1
ii  libmail-dkim-perl0.54-1
pn  libnet-ldap-perl 
pn  libsnmp-perl 
pn  libzeromq-perl   
ii  lzop 1.03-4+b1
ii  nomarch  1.4-3+b2
ii  p7zip16.02+dfsg-6
pn  rpm  
ii  spamassassin 3.4.2-1+deb10u2
ii  unrar1:5.6.6-1

-- Configuration Files:
/etc/amavis/conf.d/05-node_id changed [not included]
/etc/amavis/conf.d/15-content_filter_mode changed [not included]
/etc/amavis/conf.d/50-user changed [not included]
/etc/init.d/amavis changed [not included]

-- no debconf information

Bug#973653: src:testinfra: Upstream project rename

[Baptiste Beauplat]

Source: testinfra
Severity: normal

I'm creating this bug report to track the project rename.

testinfra has moved its code under the pytest-dev github group in order 
to enable a more collaborative development of the plugin [1]. The 
upstream project live now at:


https://github.com/pytest-dev/pytest-testinfra

To fit the naming convention requirement of pytest-dev, the repository 
has been renamed to pytest-testinfra [2].


Following along, the project itself as well as the pypi release have 
also been renamed. The only name that hasn't changed is the module name.


In addition to the pytest naming convention, renaming the project has 
also permitted to move away from the confusion between testinfra and 
test-infra [3].


Given that:
  - The testinfra name can be a source of confusion
  - Upstream has renamed its project
  - testinfra is currently only available in unstable

I intend to rename the source package to the new name pytest-testinfra. 
The binary name will be renamed according to the Debian python policy as 
python3-testinfra.


Here are the list of step to follow in order to complete the rename in 
Debian:


- Move the Debian packaging repository on salsa (done)
- Update VCS links (done)
- Update the source package name, in debian changelog, control file and 
copyright (done)

- Declare approriate Breaks, Replaces, Provides (done)
- Upload pytest-testinfra to NEW
- Request removal of testinfra

[1]: https://github.com/pytest-dev/pytest-testinfra/issues/484
[2]: https://github.com/pytest-dev/meta/issues/1
[3]: https://github.com/kubernetes/test-infra
--
Baptiste BEAUPLAT - lyknode


OpenPGP_0x1EDBAA3C6926AF92.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Bug#842683: IA32 build of OVMF (EDK2)

[Ryutaroh Matsumoto]

Hi everyone,

I have successfully built IA32 OVMF and verified its functionality
with qemu-system-i386, for its detail please have a look at

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973571

which was merged with this 842683.

Best regards, Ryutaroh Matsumoto

Bug#973652: xfce4-helpers: missing Breaks+Replaces: libexo-common (<< 4.15)

[Andreas Beckmann]

Package: xfce4-helpers
Version: 4.15.2-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../xfce4-helpers_4.15.2-1_amd64.deb ...
  Unpacking xfce4-helpers (4.15.2-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/xfce4-helpers_4.15.2-1_amd64.deb (--unpack):
   trying to overwrite '/etc/xdg/xfce4/helpers.rc', which is also in package 
libexo-common 0.12.11-1
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/xfce4-helpers_4.15.2-1_amd64.deb


cheers,

Andreas


libexo-common=0.12.11-1_xfce4-helpers=4.15.2-1.log.gz
Description: application/gzip

Bug#973650: ITP: hts-nim-tools -- tools biological sequences: bam-filter, count-reads, vcf-check

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: hts-nim-tools -- tools biological sequences: bam-filter, 
count-reads, vcf-check
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: hts-nim-tools
  Version : 0.2.0
  Upstream Author : Brent Pedersen <@brentp>
* URL : https://github.com/brentp/hts-nim-tools
* License : MIT
  Programming Lang: (C, C++, C#, Perl, Python, etc.)
  Description : tools biological sequences: bam-filter, count-reads, 
vcf-check
 This package provides several tools that (at least at the time of their 
creation)
 provide functionalities beyond the routine provided by samtools and other 
reverse
 dependencies of the htslib.
 .
 These new tools are
  • bam-filter: filter BAM/CRAM/SAM files with a simple expression language
  • count-reads   : count BAM/CRAM reads in regions given in a BED file
  • vcf-check : check regions of a VCF against a background for missing 
chunks
 .
 and yes, as the name suggests, these tools are all implemented in nim, using 
the
 nim-hts (upstream: hts-nim) wrapper for the htslib.

Remark: This package is maintained by Steffen Moeller at
   https://salsa.debian.org/med-team/hts-nim-tools

Bug#973651: libqb-tools: missing Breaks+Replaces: libqb-dev (<< 2)

[Andreas Beckmann]

Package: libqb-tools
Version: 2.0.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../libqb-tools_2.0.1-1_amd64.deb ...
  Unpacking libqb-tools (2.0.1-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libqb-tools_2.0.1-1_amd64.deb (--unpack):
   trying to overwrite '/usr/sbin/qb-blackbox', which is also in package 
libqb-dev 1.0.6-2
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/libqb-tools_2.0.1-1_amd64.deb
 

cheers,

Andreas


libqb-dev=1.0.6-2_libqb-tools=2.0.1-1.log.gz
Description: application/gzip

Bug#973647: libc-bin: iconv does not support C.UTF-8

[Vincent Lefevre]

On 2020-11-02 20:41:02 +0100, Vincent Lefevre wrote:
> With en_US.utf8, no issues:
> 
> $ export LC_ALL=en_US.utf8
> $ echo a─b | iconv -f utf-8 -t ascii//TRANSLIT
> a-b
> 
> But with C.UTF-8, the character "─" is regarded as invalid:
> 
> $ export LC_ALL=C.UTF-8
> $ echo a─b | iconv -f utf-8 -t ascii//TRANSLIT
> aiconv: illegal input sequence at position 1

Note that this is not related to the charset used by the file,
but the locale under which iconv runs. For instance, there is
no issue to convert a UTF-8 files under the C locale, but using
C.UTF-8 instead yields an error:

$ echo a─b | LC_ALL=C iconv -f utf-8 -t ascii//TRANSLIT
a-b
$ echo a─b | LC_ALL=C.UTF-8 iconv -f utf-8 -t ascii//TRANSLIT
aiconv: illegal input sequence at position 1

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#973649: ITP: --

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP:  -- 
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: 
  Version : 
  Upstream Author : 
* URL : 
* License : 
  Programming Lang: (C, C++, C#, Perl, Python, etc.)
  Description : 


Remark: This package is maintained by  at
   

Bug#973648: libgladeui-2-13: missing Breaks+Replaces: libgladeui-2-6

[Andreas Beckmann]

Package: libgladeui-2-13
Version: 3.38.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../libgladeui-2-13_3.38.1-1_amd64.deb ...
  Unpacking libgladeui-2-13:amd64 (3.38.1-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libgladeui-2-13_3.38.1-1_amd64.deb (--unpack):
   trying to overwrite 
'/usr/lib/x86_64-linux-gnu/glade/modules/libgladegtk.so', which is also in 
package libgladeui-2-6:amd64 3.22.2-2
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/libgladeui-2-13_3.38.1-1_amd64.deb


cheers,

Andreas


libgladeui-2-6=3.22.2-2_libgladeui-2-13=3.38.1-1.log.gz
Description: application/gzip

Bug#973571: ovmf: does not work with qemu-system-i386 5.1

[Ryutaroh Matsumoto]

Control: reassign -1 src:edk2
Control: forcemerge -1 842683

>> I wonder if there is a good reason NOT building IA32 OVMF...
>> I have no idea about that...
> 
> I would guess that the maintainers might have face similar problems to
> #842683 and that these problems have been fixed upstream in the mean
> time, but that is just speculation...

My uninformed guess is that use cases of IA32 OVMF were too few,
and now they seem increasing as autopkgtest-virt-qemu will probably
support UEFI boot for the i386 architecture.

I am hoping the above control commands merge 973571 and 842683
(I don't know how to merge multiple BTS bugs...).

Best regards, Ryutaroh

Bug#972278: transition: qtbase-opensource-src

[Lisandro Damián Nicanor Pérez Meyer]

Hi!

On Mon, 2 Nov 2020 at 14:21, Dmitry Shachnev  wrote:
>
> Hi Paul!
>
> On Sun, Nov 01, 2020 at 09:30:19PM +0100, Paul Gevers wrote:
> > The trigger normally doesn't change which packages get installed, just
> > their version. It's possible that during a transition, apt-get finds the
> > wrong solution for the desired set, but once everything is rebuilt, that
> > problem normally goes away. So, if the test is run against
> > qtbase-opensource-src-gles, than either that's required due to a Depends
> > or a test dependency.
> >
> > britney also adds triggers for source packages involved in versioned
> > Breaks/Replaces and the like if those are different for testing and
> > unstable.
> >
> > I hope this clarifies?
>
> This makes sense, thanks!
>
> Lisandro found the reason — that test is failing because it depends on
> qt5-default package, which we removed. He filed #973607 for that issue.

In fact I did not mention this because I managed to fix the packages
reported by dak in time for the transition. Yes, I am an old schooler
that was used to use dak for this cases... Now I've learned that this
is no longer true, as dak does not takes into accounts autopkgtests
(but maybe it should? Or maybe -Rnb is not enough?).

> It was not easy to find this reason because the test log doesn't even
> mention qt5-default.

This is indeed strange, as the package is clearly listed in tests/control.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#973647: libc-bin: iconv does not support C.UTF-8

[Vincent Lefevre]

Package: libc-bin
Version: 2.31-4
Severity: normal

With en_US.utf8, no issues:

$ export LC_ALL=en_US.utf8
$ echo a─b | iconv -f utf-8 -t ascii//TRANSLIT
a-b

But with C.UTF-8, the character "─" is regarded as invalid:

$ export LC_ALL=C.UTF-8
$ echo a─b | iconv -f utf-8 -t ascii//TRANSLIT
aiconv: illegal input sequence at position 1

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.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 libc-bin depends on:
ii  libc6  2.31-4

Versions of packages libc-bin recommends:
ii  manpages  5.08-1

libc-bin suggests no packages.

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#966671: coturn: unlimited number of /var/log/turn_*.log are created

[Jonas Smedegaard]

Quoting Tobias Frost (2020-11-02 20:24:04)
> Control: severity -1 minor
> 
> Fixing severity, the mail from Jonas seems not do have done things…

Thanks!

Hmm - seems "Control:" is case-sensitive.  Good to know!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#966671: coturn: unlimited number of /var/log/turn_*.log are created

[Tobias Frost]

Control: severity -1 minor

Fixing severity, the mail from Jonas seems not do have done things…

On Thu, 29 Oct 2020 21:06:45 +0100 Jonas Smedegaard  wrote:
> Package: coturn
> Version: 4.5.1.3-1
> Followup-For: Bug #966671
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> control: severity -1 minor
> 
> The package _permits_ the user to spew endless logfiles,
> but by default rely on syslog, which by default rotates logfiles.
> 
> I see no bug here, but let's keep it at minor severity for now...
> 
>  - Jonas
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl+bINIACgkQLHwxRsGg
> ASEknQ//eAwFjY+FBxMKbhgrjzeoJ6ewOfeXUrgNJuAqF5f7xYadvEUq9XkgjVHL
> yayjGvwZOy2ZugfOxzyuk7HS5LpZhxJwqMR7EeVUZBSSUX4EHevqgaw4A0j7lPoa
> XW38C2c1AXXUKH6njSRz3jAlLhTgJSNPrQ/0DZJ1zmGS5hssCee+0DHTuzkTdaUT
> ztMCex124B7ua59eEjDwKbfYhmRclCLFkkxU6sEoV2nxpx5k9wflGJK4By9IGwnP
> uw3toKRoeyqFKh1AK0AdtAk192ZJuPqyZUWUsXR6NAqYu8Gn290Q+0/BuWCeZGN1
> tfIHRnHTjszQqL9Ooq4rpoinA40OTgFIpV1cE9MeLTf6AAkT6Zbt6w81UMA7XKgi
> JZBPL5s1U+rx5Rac5H3ugWNbKUsvwB5rpm2WVA2W+IYeJzAQyaluOFKDzZ869JNO
> IPDzHqCUfWTCtPMZpnlOumaXRP4Q5W+5ZYSfFMANmd/W54f6dGMUL39VqNdfYTAS
> pEKnj+pGH6Fx05jSfSK347dKVbTSyTcLsen1CUf21sERV8QgE9gHhGLwoJvpEnA4

> SC6GZa7Dez5DPygwzWx9X8zdGt33tFAsXN1gOmkEvhkJCXcvnrnqknnvB2CgoytA
> zID65t1h/Gc7oGXXVDZTqzaFdmujYbmTRMe8up4S97ETFzz6kaQ=
> =gCo4
> -END PGP SIGNATURE-
> 
> 

Bug#972928: claws-mail: Crash when attempted to enter IMAP folder

[Bernhard Übelacker]

Dear Maintainer,
I just came across this report and want to note that since ASLR
got quite common the addr2line method is unreliable.

Therefore I want to point to here [1], were another method is
described to find out the source line where a crash happened. 

Attached file contains this exercised for the given output
in the first message.
This would point to [3], folderview.c, line 2339.

The most convenient way I guess is to install a coredump collector,
and inspect that after a crash like in [2] you already mentioned.

Kind regards,
Bernhard


[1] https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash
[2] https://wiki.debian.org/HowToGetABacktrace
[3] https://sources.debian.org/src/claws-mail/3.17.3-2/src/folderview.c/#L2339



dmesg: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972928#5
[Mon Oct 26 10:23:55 2020] claws-mail[1879911]: segfault at 1f ip 
004a35bd sp 7ffe5872a4e0 error 4 in claws-mail[442000+23]
[Mon Oct 26 10:23:55 2020] Code: 30 85 c0 0f 84 a4 02 00 00 c7 05 3e f6 2e 00 
00 00 00 00 31 f6 48 89 df e8 c0 fc ff ff 49 8b 84 24 88 00 00 00 48 85 c0 74 
19 <48> 8b 00 31 f6 83 38 04 48 8b 43 50 40 0f 94 c6 48 8b 78 30 e8 5a


https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash

0: no page found
0: read access
1: user-mode access


benutzer@debian:~$ echo -n "find /b ..., ..., 0x" && \
> echo "30 85 c0 0f 84 a4 02 00 00 c7 05 3e f6 2e 00 00 00 00 00 31 f6 48 89 df 
> e8 c0 fc ff ff 49 8b 84 24 88 00 00 00 48 85 c0 74 19 <48> 8b 00 31 f6 83 38 
> 04 48 8b 43 50 40 0f 94 c6 48 8b 78 30 e8 5a" \
>  | sed 's/[<>]//g' | sed 's/ /, 0x/g'
find /b ..., ..., 0x30, 0x85, 0xc0, 0x0f, 0x84, 0xa4, 0x02, 0x00, 0x00, 0xc7, 
0x05, 0x3e, 0xf6, 0x2e, 0x00, 0x00, 0x00, 0x00, 0x00, 0x31, 0xf6, 0x48, 0x89, 
0xdf, 0xe8, 0xc0, 0xfc, 0xff, 0xff, 0x49, 0x8b, 0x84, 0x24, 0x88, 0x00, 0x00, 
0x00, 0x48, 0x85, 0xc0, 0x74, 0x19, 0x48, 0x8b, 0x00, 0x31, 0xf6, 0x83, 0x38, 
0x04, 0x48, 0x8b, 0x43, 0x50, 0x40, 0x0f, 0x94, 0xc6, 0x48, 0x8b, 0x78, 0x30, 
0xe8, 0x5a
benutzer@debian:~$









# Buster/stable amd64 qemu VM 2020-11-02


apt update
apt dist-ugprade


apt install systemd-coredump gdb claws-mail claws-mail-dbgsym



gdb -q 
set width 0
set pagination off
file /usr/bin/claws-mail
tb main
run

info target

0x00448cb0 - 0x006715b1 is .text

(gdb) find /b 0x00448cb0, 0x006715b1, 0x30, 0x85, 0xc0, 0x0f, 
0x84, 0xa4, 0x02, 0x00, 0x00, 0xc7, 0x05, 0x3e, 0xf6, 0x2e, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x31, 0xf6, 0x48, 0x89, 0xdf, 0xe8, 0xc0, 0xfc, 0xff, 0xff, 0x49, 
0x8b, 0x84, 0x24, 0x88, 0x00, 0x00, 0x00, 0x48, 0x85, 0xc0, 0x74, 0x19, 0x48, 
0x8b, 0x00, 0x31, 0xf6, 0x83, 0x38, 0x04, 0x48, 0x8b, 0x43, 0x50, 0x40, 0x0f, 
0x94, 0xc6, 0x48, 0x8b, 0x78, 0x30, 0xe8, 0x5a
0x4a3593 
1 pattern found.

(gdb) b * (0x4a3593 + 42)
Breakpoint 2 at 0x4a35bd: file folderview.c, line 2339.
(gdb) info b
Num Type   Disp Enb AddressWhat
2   breakpoint keep y   0x004a35bd in folderview_selected at 
folderview.c:2339

(gdb) disassemble /r 0x4a3593, 0x4a3593 + 62
Dump of assembler code from 0x4a3593 to 0x4a35d1:
   0x004a3593 :30 85 c0 0f 84 a4   
xor%al,-0x5b7bf040(%rbp)
   0x004a3599 :02 00   
add(%rax),%al
   0x004a359b :00 c7   
add%al,%bh
   0x004a359d :05 3e f6 2e 00  
add$0x2ef63e,%eax
   0x004a35a2 :00 00   
add%al,(%rax)
   0x004a35a4 :00 00   
add%al,(%rax)
   0x004a35a6 :31 f6   
xor%esi,%esi
   0x004a35a8 :48 89 df
mov%rbx,%rdi
   0x004a35ab :e8 c0 fc ff ff  
callq  0x4a3270 
   0x004a35b0 :49 8b 84 24 88 00 00 00 
mov0x88(%r12),%rax
   0x004a35b8 :48 85 c0
test   %rax,%rax
   0x004a35bb :74 19   
je 0x4a35d6 
   0x004a35bd :   >>>  48 8b 00
mov(%rax),%rax
   0x004a35c0 :31 f6   
xor%esi,%esi
   0x004a35c2 :83 38 04
cmpl   $0x4,(%rax)
   0x004a35c5 :48 8b 43 50 
mov0x50(%rbx),%rax
   0x004a35c9 :40 0f 94 c6 
sete   %sil
   0x004a35cd :48 8b 78 30 
mov0x30(%rax),%rdi
End of assembler dump.
(gdb) print 0x88
$2 = 136


(gdb) ptype /o FolderView
type = struct _FolderView {
/*0  | 8 */GtkWidget *scrolledwin;
/*8  | 8 */GtkWidget *ctree;
/*   16  | 8 */GtkWidget *headerpopupmenu;
/*   24  | 8 */GHashTable *popups;
/*   32  | 8 */GtkCMCTreeNode *selected;
/*   40  | 8 */GtkCMCTreeNode *opened;
/*   48  | 4 */gboolean open_folder;
/*   52  |12 */

Bug#973646: qtgraphicaleffects-opensource-src: FTBFS on hppa: qmlcachegen bad access

[John David Anglin]

Source: qtgraphicaleffects-opensource-src
Version: 5.15.1-2
Severity: normal

Dear Maintainer,

The qtgraphicaleffects-opensource-src packages fails to build on hppa
because of out-of-bounds accesses by qmlcachegen.  See for example the
following build log:
https://buildd.debian.org/status/fetch.php?pkg=qtgraphicaleffects-opensource-src=hppa=5.15.1-2=1604339751=0

The following page faults are shown on the console:

do_page_fault() command='qmlcachegen' type=15 address=0xf98c4020 in 
qmlcachegen[1+c5000]
trap #15: Data TLB miss fault, vm_start = 0xf90c4000, vm_end = 0xf98c4000

do_page_fault() command='qmlcachegen' type=15 address=0xfaed5000 in 
libQt5Core.so.5.15.1[f7f28000+5e6000]
trap #15: Data TLB miss fault, vm_start = 0xfa6d5000, vm_end = 0xfaed5000

do_page_fault() command='qmlcachegen' type=15 address=0xf99b9000 in 
libQt5Core.so.5.15.1[f7f28000+5e6000]
trap #15: Data TLB miss fault, vm_start = 0xf91b9000, vm_end = 0xf99b9000

As can be seen, qmlcachegen faults on accesses past the end of the vm region.

The actual bug is probably in qtdeclarative-opensource-src.

Regards,
Dave Anglin

-- System Information:
Debian Release: bullseye/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 5.8.18+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#973645: transition: log4cplus

[Tobias Frost]

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

Hi release-team,

transition time again :)

This time, log4cplus… 

https://release.debian.org/transitions/html/auto-log4cplus.html
seems to have picked it up correctly.

I've rebuilt the mentioned r-deps already successfully.

isc-kea -- FTBFS in sid currently, but builds fine with the version in VCS
   (FTBFS unrelated to the transition #973641)

openvdb -- builds fine with new version.

Waiting for your green light…

-- 
Cheers,
tobi

Bug#973644: mes should be Architecture: amd64 armel armhf i386

[Adrian Bunk]

Source: mes
Version: 0.22-4
Severity: important
Tags: ftbfs

"amd64 armel armhf i386" are the architectures supported upstream
(32bit arm needs some files that are in upsteam but missing in the
 0.22 release tarball).

Bug#973643: loudmouth: build against krb5-multidev for GSSAPI SASL support

[Jelmer Vernooij]

Source: loudmouth
Severity: wishlist

Dear Maintainer,

Please consider adding krb5-multidev to the build-dependencies of
loudmouth, to enable support for the GSSAPI SASL mechanism.

(configure will pick this up automatically if the GSSAPI library is
present)

Suggested patch attached; matching merge request in 
https://salsa.debian.org/xmpp-team/loudmouth/-/merge_requests/1

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
=== modified file 'debian/changelog'
--- old/debian/changelog2019-02-17 23:28:16 +
+++ new/debian/changelog2020-11-02 18:22:48 +
@@ -1,3 +1,9 @@
+loudmouth (1.5.3-6) UNRELEASED; urgency=medium
+
+  * Add dependency on krb5-multidev, to enable SASL GSSAPI support.
+
+ -- Jelmer Vernooij   Mon, 02 Nov 2020 18:22:46 +
+
 loudmouth (1.5.3-5) unstable; urgency=medium
 
   * Add support for IPv6 (Closes: #921195)

=== modified file 'debian/control'
--- old/debian/control  2019-02-17 23:28:16 +
+++ new/debian/control  2020-11-02 18:22:48 +
@@ -9,7 +9,8 @@
libgnutls28-dev (>= 3.0.20),
libidn11-dev,
libasyncns-dev,
-   check
+   check,
+   krb5-multidev
 Standards-Version: 4.3.0
 Rules-Requires-Root: no
 Vcs-Browser: https://salsa.debian.org/xmpp-team/loudmouth

Bug#973637: flag debian/watch files that use older versions of the format

[Felix Lechner]

Hi Jelmer

On Mon, Nov 2, 2020 at 9:57 AM Jelmer Vernooij  wrote:
>
> It would be great if lintian could flag debian/watch files that didn't use a
> watch file format version or use an older version (< 4).

Can you just use the existing classification tag
debian-watch-file-standard [1] [2]? It will give you the version.

Please feel free to close if that tag works for you. Thanks!

Kind regards
Felix Lechner

[1] 
https://salsa.debian.org/lechner/lintian/-/blob/master/checks/debian/watch.pm#L134
[2] 
https://salsa.debian.org/lechner/lintian/-/blob/master/tags/d/debian-watch-file-standard.desc

Bug#973642: RFS: fonts-joscelyn/1.012+ds-1 [ITP] -- authentic secretary hand font

[Gürkan Myczko]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "fonts-joscelyn":

 * Package name: fonts-joscelyn
   Version : 1.012+ds-1
   Upstream Author : Peter S. Baker 
 * URL : https://github.com/psb1558/Joscelyn-font
 * License : OFL-1.1
 * Vcs : https://salsa.debian.org/fonts-team/fonts-joscelyn
   Section : fonts

It builds those binary packages:

  fonts-joscelyn - authentic secretary hand font

To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/fonts-joscelyn/

Alternatively, one can download the package with dget using this 
command:


  dget -x 
https://mentors.debian.net/debian/pool/main/f/fonts-joscelyn/fonts-joscelyn_1.012+ds-1.dsc


Changes for the initial release:

 fonts-joscelyn (1.012+ds-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #966268)

Regards,
--
  Gürkan Myczko

Bug#973640: ITP: ruby-safety-net-attestation -- SafetyNet attestation response verification

[Pirate Praveen]

Package: wnpp
severity: wishlist
Owner: Pirate Praveen 

Packaging of https://rubygems.org/gems/safety_net_attestation

Bug#971415: transition: ocaml

[Paul Gevers]

HI Stéphane,

On 02-11-2020 16:56, Stéphane Glondu wrote:
>> autopkgtest for ocaml-cairo2/0.6.1+dfsg-5: amd64: Regression ♻ (reference 
>> ♻), arm64: Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), 
>> i386: Regression ♻ (reference ♻), ppc64el: Regression ♻ (reference ♻)
> 
> However, I don't understand why it complains about
> ocaml-cairo2/0.6.1+dfsg-5 whereas version 0.6.1+dfsg-6 is fixed. Does
> something need to be done?

Your symptoms describe a missing *versioned* Depends/Breaks or test
dependency. The migration software tries run tests with the minimum
changes. So, if nothing makes sure that the version from unstable is
needed, it will run with as much packages as possible from testing. What
we see in the logs is that it installs the test suite from testing.
Then, the test dependencies are installed and apt-get reports that it
can't install the required packages. It then falls back to enable
everything from unstable and then installation is possible.

Do you confirm that the issue is only in the test? I think we can ignore
this issue then (or better, trigger the test manually with ocaml-cairo2
from unstable. With the description above, do you understand why the
relations in the packages don't teach our migration software what to do?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#973639: libgromacs6: missing Breaks+Replaces: libgromacs5

[Andreas Beckmann]

Package: libgromacs6
Version: 2021~beta1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../libgromacs6_2021~beta1-1_amd64.deb ...
  Unpacking libgromacs6:amd64 (2021~beta1-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libgromacs6_2021~beta1-1_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/x86_64-linux-gnu/libgmxapi.so.0.1.0', which is 
also in package libgromacs5:amd64 2020.4-2
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/libgromacs6_2021~beta1-1_amd64.deb
 
Shared libraries with independent soversions shouldn't be bundled in the same
binary package.


cheers,

Andreas


libgromacs5=2020.4-2_libgromacs6=2021~beta1-1.log.gz
Description: application/gzip

Bug#973637: flag debian/watch files that use older versions of the format

[Jelmer Vernooij]

Package: lintian
Version: 2.100.0
Severity: wishlist

It would be great if lintian could flag debian/watch files that didn't use a
watch file format version or use an older version (< 4).

See also https://salsa.debian.org/jelmer/debian-janitor/-/issues/144


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

Kernel: Linux 5.7.0-1-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 lintian depends on:
ii  binutils2.35.1-2
ii  bzip2   1.0.8-4
ii  diffstat1.63-1
ii  dpkg1.20.5
ii  dpkg-dev1.20.5
ii  file1:5.38-5
ii  gettext 0.19.8.1-10
ii  gpg 2.2.20-1
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.36+b3
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b5
ii  libclone-perl   0.45-1
ii  libconfig-tiny-perl 2.24-1
ii  libcpanel-json-xs-perl  4.25-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1
ii  libdevel-size-perl  0.83-1+b1
ii  libdpkg-perl1.20.5
ii  libemail-address-xs-perl1.04-1+b2
ii  libfile-basedir-perl0.08-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1
ii  libhtml-html5-entities-perl 0.004-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004002-1
ii  liblist-compare-perl0.55-1
ii  liblist-moreutils-perl  0.416-1+b5
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.004000-1
ii  libmoox-aliases-perl0.001006-1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.114-1
ii  libperlio-gzip-perl 0.19-1+b6
ii  libproc-processtable-perl   0.59-2
ii  libsereal-decoder-perl  4.018+ds-1
ii  libsereal-encoder-perl  4.018+ds-1
ii  libtext-glob-perl   0.11-1
ii  libtext-levenshteinxs-perl  0.03-4+b7
ii  libtext-markdown-discount-perl  0.12-1
ii  libtext-xslate-perl 3.5.8-1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b2
ii  libtimedate-perl2.3300-1
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.010006-1
ii  libunicode-utf8-perl0.62-1+b1
ii  liburi-perl 5.05-1
ii  libxml-libxml-perl  2.0134+dfsg-2
ii  libyaml-libyaml-perl0.82+repack-1
ii  lzip1.21-8
ii  lzop1.04-1
ii  man-db  2.9.3-2
ii  patchutils  0.4.2-1
ii  perl [libdigest-sha-perl]   5.30.3-4
ii  t1utils 1.41-4
ii  unzip   6.0-25
ii  xz-utils5.2.4-1+b1

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.59-1

-- no debconf information

Bug#973638: RM: calcoo/-1 -- ROM; gtk2-only, no longer maintained

[Jonathan Carter]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-rele...@lists.debian.org, j...@debian.org

Please remove calcoo.

It's GTK-2 only and no one is porting it to GTK-3.

Upstream haven't made any updates either in some years now.

thanks,

Bug#973636: golang-github-nicksnyder-go-i18n.v2-dev,golang-github-nicksnyder-go-i18n-dev: duplicate packages?

[Andreas Beckmann]

Package: 
golang-github-nicksnyder-go-i18n.v2-dev,golang-github-nicksnyder-go-i18n-dev
Version: 2.1.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../golang-github-nicksnyder-go-i18n-dev_2.1.1-2_all.deb 
...
  Unpacking golang-github-nicksnyder-go-i18n-dev (2.1.1-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/golang-github-nicksnyder-go-i18n-dev_2.1.1-2_all.deb 
(--unpack):
   trying to overwrite 
'/usr/share/gocode/src/github.com/nicksnyder/go-i18n/v2/i18n/bundle.go', which 
is also in package golang-github-nicksnyder-go-i18n.v2-dev 2.1.1-1
  Errors were encountered while processing:
   /var/cache/apt/archives/golang-github-nicksnyder-go-i18n-dev_2.1.1-2_all.deb


These files are shipped by both packages:

usr/share/gocode/src/github.com/nicksnyder/go-i18n/v2/i18n/bundle.go
usr/share/gocode/src/github.com/nicksnyder/go-i18n/v2/i18n/bundle_test.go
usr/share/gocode/src/github.com/nicksnyder/go-i18n/v2/i18n/doc.go
usr/share/gocode/src/github.com/nicksnyder/go-i18n/v2/i18n/example_test.go
usr/share/gocode/src/github.com/nicksnyder/go-i18n/v2/i18n/language_test.go
usr/share/gocode/src/github.com/nicksnyder/go-i18n/v2/i18n/localizer.go
usr/share/gocode/src/github.com/nicksnyder/go-i18n/v2/i18n/localizer_test.go
usr/share/gocode/src/github.com/nicksnyder/go-i18n/v2/i18n/message.go
usr/share/gocode/src/github.com/nicksnyder/go-i18n/v2/i18n/message_template.go
usr/share/gocode/src/github.com/nicksnyder/go-i18n/v2/i18n/message_template_test.go
usr/share/gocode/src/github.com/nicksnyder/go-i18n/v2/i18n/message_test.go
usr/share/gocode/src/github.com/nicksnyder/go-i18n/v2/i18n/parse.go
usr/share/gocode/src/github.com/nicksnyder/go-i18n/v2/i18n/parse_test.go
usr/share/gocode/src/github.com/nicksnyder/go-i18n/v2/internal/plural/doc.go
usr/share/gocode/src/github.com/nicksnyder/go-i18n/v2/internal/plural/form.go
usr/share/gocode/src/github.com/nicksnyder/go-i18n/v2/internal/plural/operands.go
usr/share/gocode/src/github.com/nicksnyder/go-i18n/v2/internal/plural/operands_test.go
usr/share/gocode/src/github.com/nicksnyder/go-i18n/v2/internal/plural/rule.go
usr/share/gocode/src/github.com/nicksnyder/go-i18n/v2/internal/plural/rule_gen.go
usr/share/gocode/src/github.com/nicksnyder/go-i18n/v2/internal/plural/rule_gen_test.go
usr/share/gocode/src/github.com/nicksnyder/go-i18n/v2/internal/plural/rule_test.go
usr/share/gocode/src/github.com/nicksnyder/go-i18n/v2/internal/plural/rules.go
usr/share/gocode/src/github.com/nicksnyder/go-i18n/v2/internal/plural/rules_test.go
usr/share/gocode/src/github.com/nicksnyder/go-i18n/v2/internal/template.go
usr/share/gocode/src/github.com/nicksnyder/go-i18n/v2/internal/template_test.go


cheers,

Andreas


golang-github-nicksnyder-go-i18n.v2-dev=2.1.1-1_golang-github-nicksnyder-go-i18n-dev=2.1.1-2.log.gz
Description: application/gzip

Bug#972417: xfce4-power-manager: System left idle => 'display power management' auto-locks session => no X session or lightdm greeter

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

control: forcemerge 870641 -1

On Sun, 2020-10-18 at 10:23 +0200, franck wrote:
> Package: xfce4-power-manager
> Version: 1.6.1-1
> Severity: grave
> 
> Dear Maintainer,
> 
> [ Bug description ]
> Bug happens when the screen auto-locks due to user inactivity. Then the
> screen switches off.
> To easily test that, set following to 1 min or so
> Xfce menu Applications -> Settings -> Power Manager -> Display -> 'Switch
> off after'
> 
> After such auto-lock, it appears not possible to get back the X session
> anymore.
> Because
> - by moving mouse or typing on keyboard the screen does not wake up. It
> stays off, black.
> - with Ctrl+Alt-F7 one gets
>     This session is locked
>     You’ll be redirected to the unlock
>     dialog automatically in a few seconds
>   but after waiting a few seconds the screen switches off again.
> => no way to get to the lightdm greeter.
> In both cases: not possible to get back the running X session anymore.

The lightdm greeter is on tty8, so try with Ctrl-Alt-F8.
> 
> => I filled this bug against xfce4-power-manager
> But I have no clue whether xfce4-power-manager
> - processes the locking completely by itself ?
> - just prepares locking, like deactivating keyboard/mouse? and then trigger
> like light-locker-command --lock...
> - only asks another package to do the full locking procedure.
> 
> 
> 
> Bug occurred under (at least) both kernels:
> linux-image-4.19.0-11-amd64-unsigned 4.19.146-1
> linux-image-5.8.0-0.bpo.2-amd64  5.8.10-1~bpo10+1
> 
> 

> 
> Also this bug gives a bad image to the user:
> - 'system crashed'
> - wondering what is the cause:
>     - is my graphic card not properly waking up ?
>     - or a bug in kernel ?
>     - or Xorg ?
>     - or light-locker ?
>     ...
> Thus they are probably numerous of open bugs that could be closed by fixing
> this bug.

Actually it's (or should be) already fixed in stable.
> 
> 
> [ Bugs reported against other packages, & that seem linked to this bug ]
> Bugs in source package light-locker
>   #906902 System left idle makes system freeze
>   #870641 light-locker, lightdm: screen stays off after resume
>   and all the merged one:
>   805711, 846278, 868087, 908329, 922095, 929461, 929834, 931555
>   #835461 light-locker breaks suspend/resume with nvidia legacy 340 drivers
> Bugs in source package lightdm
>   #867620 lightdm unlock screen randomly doesn't appear

With all those bugs already opened and the mess we're already in, why opening
*yet another one*? Honestly it adds more confusion than anything at that
point.

As indicated in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870641#218
the bug *should* be fixed in 10.5 with kernel 4.19.0-10. You indicated that
you tested with linux-image-4.19.0-11-amd64-unsigned 4.19.146-1

Can you retry with that kernel and check you have the “atomic” message in the
kernel log:

broken atomic modeset userspace detected, disabling atomic

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl+gRRsACgkQ3rYcyPpX
RFvT2Qf+K/oere1FxlQi2jg+f/iL6ejQLL/jowc5R3pg34Jp3jJMPvWe6HYz7c2L
+88W5GqwhI88Qk5oiGMdEf+3s8eKwoJi2kBp92g6HFyk6Xjbe7vzs7FOhUeeHadE
9ezgXfKzrDlhM4Knm3JtTEgKbgnEeOSop78hfzkaTrH94sbR75taK8yMo7Yuec3i
gIezlzkkOTuT37oDzrG2hyD9A/mEnQTWw3pw97kqHZo3meEtTjwZ9/vutd2MuzQM
zJG5qpCLH7G8fywBWzW6SZSDhChAo44Phz2fHDmlPLKtHUTAn03nHPwkdgUgg0Kw
3iaNBwgSZaPfZrPRh4yIhhN9rUodhQ==
=SWS6
-END PGP SIGNATURE-

Bug#940914: uno-libs3: Segfault on launch in cppu::_copyConstructAnyFromData

[Rene Engelhard]

Hi,

to answer myself:

Am 02.11.20 um 12:14 schrieb r...@rene-engelhard.de:
> Am 2. November 2020 10:23:49 MEZ schrieb Witold Baryluk 
> :
>> I wasn't able to use libreoffice for almost 2 years on Debian, on
>> multiple machines.
> Then you should have provided needed info in those 2 years? It's not tagged 
> unreproducible, moreinfo just for fun. ;-)
>
> Most people do not have your problem as otherwise there would be far more 
> reports...
> [...]
> One idea: What happens if you are not collecting Translations, Help, 
> Dictionaries, Thesauri and Hyphenation patterns you probably won't need all 
> and reduce it to stuff you need?
>
> I could imagine (yeah, would be a bug, but..) that bring a problem.

Hmm, no, works here. (pure sid chroot + apt install libreoffice + apt
install mythes + aptitude and installing hunspell-* and myspell-* with
conflict resolution

Regards,

Rene

Bug#973634: mpich: d/copyright does not mention vis.js

[Sean Whitton]

Source: mpich
Version: 3.4~a2+really3.3.2-2
Severity: serious
Justification: Policy 2.3, 4.5, 12.5
X-Debbugs-CC: ftpmas...@debian.org

Hello,

d/copyright does not mention debian/missing-sources/vis.js, which has a
different license and copyright.  Same goes for the minified copies of
vis.js in the source.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#973635: python-is-python3: missing Breaks+Replaces: python-minimal

[Andreas Beckmann]

Package: python-is-python3
Version: 3.8.6-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

 Preparing to unpack .../python-is-python3_3.8.6-1_all.deb ...
  Unpacking python-is-python3 (3.8.6-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python-is-python3_3.8.6-1_all.deb (--unpack):
   trying to overwrite '/usr/bin/python', which is also in package 
python-minimal 2.7.16-1
  Errors were encountered while processing:
   /var/cache/apt/archives/python-is-python3_3.8.6-1_all.deb

(Same as #973273, but for python-is-python3)


cheers,

Andreas


python-minimal=2.7.16-1_python-is-python3=3.8.6-1.log.gz
Description: application/gzip

Bug#973632: python3-ledger: segfault on import

[Alexander Inyukhin]

Package: python3-ledger
Version: 3.2.1-6+b1
Severity: important

Module ledger fails to load.

$ python3 -c "import ledger"
Segmentation fault

Also, package deps are looking weird: python3 3.8, but libpython3.9.
  python3 (<< 3.9), python3 (>= 3.8~), libboost-python1.71.0-py39, libpython3.9 
(>= 3.9.0~b4)

-- System Information:
Debian Release: 10.6
Architecture: i386 (i686)

Versions of packages python3-ledger depends on:
ii  libboost-filesystem1.71.0   1.71.0-7+b1
ii  libboost-iostreams1.71.01.71.0-7+b1
ii  libboost-python1.71.0 [libboost-python1.71.0-py39]  1.71.0-7+b1
ii  libboost-regex1.71.0 [libboost-regex1.71.0-icu67]   1.71.0-7+b1
ii  libc6   2.31-4
ii  libgcc-s1   10.2.0-15
ii  libgmp102:6.1.2+dfsg-4
ii  libicu6767.1-4
ii  libmpfr64.0.2-1
ii  libpython3.93.9.0-5
ii  libstdc++6  10.2.0-15
ii  python3 3.8.2-3

Bug#973633: emacs-common: Please apply upstream patch to fix regression of schemas.xml

[Yasuhiro KIMURA]

Package: emacs-common
Version: 1:27.1+1-2
Severity: normal
X-Debbugs-Cc: Yasuhiro KIMURA , yasu.kim...@gmail.com
File: /usr/share/emacs/27.1/etc/schema/schemas.xml

Dear Maintainer,

/usr/share/emacs/27.1/etc/schema/schemas.xml is used for nXML mode to
decide which schema file should be used for specified XML file. When
upstream updated Org to 9.3, most lines of this file are removed by
mistake. This problem is reported to upstream as following bug report.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42851

This is obvious regression from 26.3. It was fixed in master branch of
upstream git repository and also merged to emacs-27 branch. So please
apply following upstream patch to this package.

https://git.savannah.gnu.org/cgit/emacs.git/patch/?id=43a1b79f56cb1ac6530e8b41f3c329890a00a8f6

Best Regards.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages emacs-common depends on:
ii  emacsen-common  3.0.4
ii  install-info6.7.0.dfsg.2-5

Versions of packages emacs-common recommends:
ii  emacs-el  1:27.1+1-2

Versions of packages emacs-common suggests:
pn  emacs-common-non-dfsg  
ii  ncurses-term   6.2+20200918-1

-- no debconf information

Bug#972278: transition: qtbase-opensource-src

[Dmitry Shachnev]

Hi Paul!

On Sun, Nov 01, 2020 at 09:30:19PM +0100, Paul Gevers wrote:
> The trigger normally doesn't change which packages get installed, just
> their version. It's possible that during a transition, apt-get finds the
> wrong solution for the desired set, but once everything is rebuilt, that
> problem normally goes away. So, if the test is run against
> qtbase-opensource-src-gles, than either that's required due to a Depends
> or a test dependency.
>
> britney also adds triggers for source packages involved in versioned
> Breaks/Replaces and the like if those are different for testing and
> unstable.
>
> I hope this clarifies?

This makes sense, thanks!

Lisandro found the reason — that test is failing because it depends on
qt5-default package, which we removed. He filed #973607 for that issue.

It was not easy to find this reason because the test log doesn't even
mention qt5-default.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#973631: python3-mdtraj: /usr/bin/mdconvert is already owned by unrelated isync package

[Andreas Beckmann]

Package: python3-mdtraj
Version: 1.9.4+git20201015.068f29a-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package python3-mdtraj.
  Preparing to unpack 
.../36-python3-mdtraj_1.9.4+git20201015.068f29a-4_amd64.deb ...
  Unpacking python3-mdtraj (1.9.4+git20201015.068f29a-4) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-qEpbdG/36-python3-mdtraj_1.9.4+git20201015.068f29a-4_amd64.deb
 (--unpack):
   trying to overwrite '/usr/bin/mdconvert', which is also in package isync 
1.3.0-2
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   
/tmp/apt-dpkg-install-qEpbdG/36-python3-mdtraj_1.9.4+git20201015.068f29a-4_amd64.deb


The isync package already ships these files since 2009:

usr/bin/mdconvert
usr/share/man/man1/mdconvert.1.gz


cheers,

Andreas


isync=1.3.0-2_python3-mdtraj=1.9.4+git20201015.068f29a-4.log.gz
Description: application/gzip

Bug#973630: fetchmail: OpenSSL library mismatch

[Francesco Paolo Lovergine]

Package: fetchmail
Version: 6.4.13-1
Followup-For: Bug #973630

I can confirm this issue and it can be solved by a rebuild by a simple bNMU.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU threads)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 fetchmail depends on:
ii  adduser   3.118
ii  debianutils   4.11.2
ii  libc6 2.31-4
ii  libcom-err2   1.45.6-1
ii  libgssapi-krb5-2  1.17-10
ii  libhesiod03.2.1-3.1
ii  libkrb5-3 1.17-10
ii  libssl1.1 1.1.1g-1
ii  lsb-base  11.1.0

Versions of packages fetchmail recommends:
ii  ca-certificates  20200601

Versions of packages fetchmail suggests:
ii  exim4-daemon-heavy [mail-transport-agent]  4.94-8
pn  fetchmailconf  
pn  resolvconf 

-- Configuration Files:
/etc/default/fetchmail changed:
OPTIONS=--nosslcertck
START_DAEMON=yes


-- no debconf information

Bug#963760: new upstream release (1.4.11)

[Daniel Baumann]

retitle new upstream release (1.4.13)
thanks

...and now there's 1.4.13.

Regards,
Daniel

Bug#973629: golang-gopkg-alecthomas-kingpin.v3-dev: missing Breaks+Replaces: golang-gopkg-alecthomas-kingpin.v2-dev

[Andreas Beckmann]

Package: golang-gopkg-alecthomas-kingpin.v3-dev
Version: 3.0~git20180227.b8d601d-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package 
golang-gopkg-alecthomas-kingpin.v3-dev.
  Preparing to unpack 
.../golang-gopkg-alecthomas-kingpin.v3-dev_3.0~git20180227.b8d601d-1_all.deb ...
  Unpacking golang-gopkg-alecthomas-kingpin.v3-dev (3.0~git20180227.b8d601d-1) 
...
  dpkg: error processing archive 
/var/cache/apt/archives/golang-gopkg-alecthomas-kingpin.v3-dev_3.0~git20180227.b8d601d-1_all.deb
 (--unpack):
   trying to overwrite '/usr/share/gocode/src/github.com/alecthomas/kingpin', 
which is also in package golang-gopkg-alecthomas-kingpin.v2-dev 2.2.6-2
  Errors were encountered while processing:
   
/var/cache/apt/archives/golang-gopkg-alecthomas-kingpin.v3-dev_3.0~git20180227.b8d601d-1_all.deb


cheers,

Andreas


golang-gopkg-alecthomas-kingpin.v2-dev=2.2.6-2_golang-gopkg-alecthomas-kingpin.v3-dev=3.0~git20180227.b8d601d-1.log.gz
Description: application/gzip

Bug#973630: fetchmail: OpenSSL library mismatch

[Giorgio P]

Package: fetchmail
Version: 6.4.13-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

after the upgrade of today fetchmail is not anymore able to
use OpenSSL. Upon calling fetchmail from mutt I get the following
fatal error.

fetchmail: Query status=2 (SOCKET)
fetchmail: Loaded OpenSSL library 0x1010107f older than headers 0x1010108f,
refusing to work.

I think it's a kind of library mismatch.

Best regards

Giorgio

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
Locale: LANG=it_CH.UTF-8, LC_CTYPE=it_CH.UTF-8 (charmap=UTF-8), 
LANGUAGE=it_CH:it
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fetchmail depends on:
ii  adduser   3.118
ii  debianutils   4.11.2
ii  libc6 2.31-4
ii  libcom-err2   1.45.6-1
ii  libgssapi-krb5-2  1.17-10
ii  libkrb5-3 1.17-10
ii  libssl1.1 1.1.1g-1
ii  lsb-base  11.1.0

Versions of packages fetchmail recommends:
ii  ca-certificates  20200601

Versions of packages fetchmail suggests:
ii  exim4-daemon-light [mail-transport-agent]  4.94-8
pn  fetchmailconf  
pn  resolvconf 

-- no debconf information

Bug#973628: nitrokey-authenticator: icon clashes with nitrokey-app

[Andreas Beckmann]

Package: nitrokey-authenticator
Version: 1.0-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package nitrokey-authenticator.
  Preparing to unpack .../9-nitrokey-authenticator_1.0-2+b1_amd64.deb ...
  Unpacking nitrokey-authenticator (1.0-2+b1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-4dNd2a/9-nitrokey-authenticator_1.0-2+b1_amd64.deb 
(--unpack):
   trying to overwrite 
'/usr/share/icons/hicolor/128x128/apps/nitrokey-app.png', which is also in 
package nitrokey-app 1.4.1-1
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-4dNd2a/9-nitrokey-authenticator_1.0-2+b1_amd64.deb

These files are shipped by both packages:

usr/share/icons/hicolor/128x128/apps/nitrokey-app.png
usr/share/icons/hicolor/16x16/apps/nitrokey-app.png
usr/share/icons/hicolor/22x22/apps/nitrokey-app.png
usr/share/icons/hicolor/24x24/apps/nitrokey-app.png
usr/share/icons/hicolor/32x32/apps/nitrokey-app.png
usr/share/icons/hicolor/48x48/apps/nitrokey-app.png
usr/share/icons/hicolor/scalable/apps/nitrokey-app.svg


cheers,

Andreas


nitrokey-app=1.4.1-1_nitrokey-authenticator=1.0-2+b1.log.gz
Description: application/gzip

Bug#973627: lintian: detect generic python cruft /usr/lib/python3/dist-packages/scripts/test.sh

[Andreas Beckmann]

Package: lintian

Hi,

I just found a new file conflict on a very generic file:
  /usr/lib/python3/dist-packages/scripts/test.sh
Please add it to the blacklist of unwanted files.

Test candidates: nanofilt (#973624), python3-nanostat (#973625)

Andreas

Bug#973626: ITP: python-i3ipc -- Python library to control i3wm and sway

[Birger Schacht]

Package: wnpp
Severity: wishlist
Owner: Birger Schacht 
X-Debbugs-Cc: debian-de...@lists.debian.org, bir...@debian.org

* Package name: python-i3ipc
  Version : 2.2.1
  Upstream Author : Tony Crisci
* URL : http://github.com/altdesktop/i3ipc-python
* License : BSD
  Programming Lang: Python
  Description : Python library to control i3wm and sway

i3ipc-python is a Python library for controlling the i3 and sway.
This project is intended to be useful for general scripting, and for
applications that interact with the window manager like status line
generators, notification daemons, and window pagers.

I intend to maintain the package within the Python Team